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

[Chad Cantwell]

You make some valid points, but there are benefits to the current behavior
as well:

1. From a security perspective, I think a 1:1 correlation between actual
filesystems makes more sense.  It is a property on the actual filesystem,
after all, and people may expect it to only share what is in that specific
filesystem.  They may even specifically not want a sub-filesystem shared.

2. If users try to move large files between zfs filesystems within what
looks like one filesystem to them, it may take much longer than expected
since it will really be a copy and delete operation instead of moving in
place.

Just due to the overhead in moving files between filesystems, and also the
current behavior of not showing sub-filesystems, the logical current
best-practice for sharing a set of directories via smb is to have them
in one filesystem to begin with.  I don't think this is necessarily a
bad thing.  If one didn't care about the speed in moving files between
the sub-filesystems, using samba instead of the in-kernel cifs is another
option already available.

If this was to be implemented, personally I think it should have a different
keyword, like sharesmb=recursive or something along those lines to indicate
explicitly that that is the desired behavior rather than changing the
existing (more secure) behavior of not recursing filesystems.  Changing the
default behavior without forcing users to choose the new behavior may also
create confusion when users switch from Solaris 11 to an Illumos-based
distro and back and can't get consistent behavior with identical zfs
property schemes.  Alternatively, you could leave sharesmb=on but set an
additional property on the child filesystems, such as inhereitsmb=on to
indicate it is to be included if the parent filesystem is shared.  This
may be a better approach since it would be possible to pick and choose
which sub-filesystems to include in the parent share.  If you even wanted
to change the default behavor by making inhereitsmb=on the default, I think
it would be less objectionable with this design, since there would at least
be a visible indication that something different is expected to happen in
contrast to the Oracle-supplied Solaris releases.

Chad Cantwell

On Sat, Jan 15, 2011 at 12:29:56AM +0200, 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
> 
> -- 
> Aram Hăvărneanu
> 
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer