I'd love to see traversal of mountpoints. Blake
On Fri, Jan 14, 2011 at 2:47 PM, Garrett D'Amore <[email protected]>wrote: > This affects CIFS. I'd like to have a reasonable timer on this... say 1 > week unless someone asks for more time. If you care about CIFS and think > this is not enough decision, please let us know! > > In the absence of feedback otherwise, I propose to wait one week. I also > think this is an interface change and deserves wider distribution, so I'm > posting to discuss@ as well. > > If you use CIFS or care about CIFS on illumos, please read this message and > give feedback, and if you need more than a week to do that, let us know! > > Timer expires on Jan 21, 2011 unless someone asks for it to be extended. > > - Garrett > > On 01/14/11 02:29 PM, Aram Hăvărneanu wrote: > >> 0. Problem: CIFS shares do not export everything under the root of the >> share, which is what CIFS users expect. >> >> Background: CIFS servers and NFS servers implement somewhat different >> ideas about what is a "share" and what it means to "share" something. >> >> In NFS, shares (exports) are essentially a property of some directory, >> and the server's path name to that directory is the share name. In most >> NFS servers, a directory can only be exported by its pathname, and >> exporting directories below an already exported directory is either not >> allowed or requires some special handling. In CIFS, shares have names >> independent of the directory exported (or "resource", i.e. printer, >> device). Multiple shares may export the same directory, possibly with >> different features (access, etc.). Shares may export multiple levels of >> the directory hierarchy (and often do), i.e. both the root of the >> filesystem and subdirectories may be shared. >> >> The OpenSolaris CIFS implementation was designed to closely match NFS >> sharing semantics, and to present a consistent administrative model >> between NFS and CIFS. Those are good goals, but the degree to which >> CIFS was made to work "just like NFS" has left CIFS users confused and >> disappointed. Probably the most common complaint goes something like: >> "It's great how I can use ZFS to create lots of filesystems, each with >> its own snapshots and quotas, etc. but when I share my filesystems for >> CIFS, none of the "child" ZFS filesystems can be seen by my clients. >> Why not?" >> >> This memo proposes modifying the behavior of ZFS "child" filesystems >> that exist below some CIFS share. There are some options in how this >> might be done, and some of those are presented for discussion, along >> with recommendations. >> >> 1. In the current implementation, the in-kernel CIFS server >> has the following behavior: >> >> 1. There is a 1:1 relation between the share and exported >> filesystems. When connecting, a client sees a separate share for >> each exported filesystem, irrespective of the server side namespace >> relation between exported filesystems thus creating a flat namespace >> on the client side. >> >> 2. While ZFS encourages a nested filesystem model, these >> nested filesystems are allowed to have properties different from >> their parents. This presents problems for exporting everything >> under some directory to CIFS clients because CIFS clients expect >> properties like "case insensitive search" to be uniform throughout >> the share. Clients request these properties for shares they connect >> to, and the server's answer constitutes a "promise" to the client >> about what semantics can be expected. The server could cause >> client-side applications to break if it were to break that promise. >> >> 3. Server side objects that are not exported to clients, >> such as mount point directories act as invisible files. Clients >> can't see them, but if they try to create files with that names, the >> create will fail mysteriously. >> >> 2. With this design, we would allow the CIFS server to >> traverse from the share's root filesystem to a child filesystem provided >> the child filesystem supports the features we guarantee to the client that >> the share supports. It does this by checking that the target filesystem >> has the same set of relevant features as the share's root filesystem. >> This set of features would be: >> >> 1. case-(in)sensitivity: the child file system should be in >> the same name lookup mode (from a case sensitive point of view) >> as the share's root filesystem. >> >> 2. ACL support: the child file system should support the same >> type of ACLs as the share's root fileystem (if any). >> >> With this design we would also implicitly solve 1.3. There are no more >> invisible and inaccessible files. Server side symlinks are followed as >> long as they are expressed relative to the share's root and they point >> to a compatible filesystem. Absolute symlinks or symlinks that point >> outside of the tree continue not to work and maintain their status of >> inaccessible files. >> >> With this proposal, there will not be any case where data was previously >> shared and now it is not. This change would causes the server to share >> a strict superset of what was previously shared, so administrators >> should not worry about some files not being shared anymore. >> >> 3. With this proposal we do not look whether the target filesystem is >> shared explicitly or not. For example is previously you had the >> following filesystem hierarchy: >> /a >> /a/1 >> /a/2 >> /a/not-shared >> /a/not-shared/1 >> >> where /a, /a/1, /a/2 have the sharesmb property set and /a/not-shared >> and /a/not-shared/1 do not. Previously, a share for /a, /a/1 and /a/2 >> will have been created and /a/not-shared and /a/not-shared/1 would be >> inaccessible on the client side. With the proposed change, only a share >> for /a, /a/1, and /a/2 will be created, just like it was the case >> before, however you will be able to access /a/not-shared* (provided file >> permissions allow this) from the client side by connecting to /a and >> traversing the filesystem from there. This is consistent with what both >> the Microsoft SMB server and Samba do. However, because the smbsrv >> property is inheritable and because a child filesystem has that property >> unset, it means that an administrator explicitly reset that property, so >> it might be interpreted that he wanted that filesystem NOT to be shared >> in any way. >> >> In Windows, with the Microsoft SMB server, shares are just convenient >> names for export points. After connecting to an SMB share, the >> Microsoft SMB server does not restrict access to the subset of files >> that reside within the share's root filesystem on the server side. >> >> This memo proposes changing the meaning of the sharesmb property in >> order to align to what Microsoft SMB server does. At the moment it is a >> switch to enable or disable exporting namespaces over wire. With this >> change it would only mean that an explicit share is created for that >> filesystem and nothing more. Setting sharesmb=no underneath another >> shared directory would no longer prevent access below that point. It >> would only cause the system to not create _another_ share at that >> directory. >> >> 4. It is open to debate whether this change in meaning is acceptable or >> not. Is it important that we check whether a child file system is >> explicitly shared (as with the current behavior) or can we just share >> everything underneath (as Microsoft SMB server does)? >> >> 5. Assuming people are OK with the changed semantics of the sharesmb >> property, it might be appropriate to also consider chaning the >> inheritance rules for this property. Rather than inherit from it's >> parent dataset, perhaps a default of sharesmb=no would be better? >> >> Signed by: Aram Hăvărneanu, Gordon Ross, Garrett D'Amore >> >> >> > > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.illumos.org/m/listinfo/discuss >
_______________________________________________ Discuss mailing list [email protected] http://lists.illumos.org/m/listinfo/discuss
