[illumos-Discuss] [illumos-Developer] RFE 604: Proposal to allow CIFS server to traverse mount points

Fri Jan 14 15:21:16 PST 2011

I'd love to see traversal of mountpoints.

Blake

On Fri, Jan 14, 2011 at 2:47 PM, Garrett D'Amore <garrett at nexenta.com>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
> Discuss at lists.illumos.org
> http://lists.illumos.org/m/listinfo/discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.illumos.org/pipermail/discuss/attachments/20110114/a78c4043/attachment.html>