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

[Garrett D'Amore]

I like the idea of a property to enable this behavior.

I do think that we should change the "default" behavior so that *new* 
filesystems get the recursive  behavior, but that previously existing 
ones don't get surprised this way while making things as easy as 
possible for new users/customers.   That said, I think the initial 
default behavior is reasonably open to debate, and I'm happy with *any* 
solution since we can always just make our product apply whatever 
default we want.

     -- Garett

On 01/14/11 04:54 PM, Chad Cantwell wrote:
> 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
>>      
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer
>