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

[Garrett D'Amore]

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
>
>