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

[Aram Hăvărneanu]

On Sat, Jan 15, 2011 at 2:54 AM, Chad Cantwell <chad at iomail.org> 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.

Actually a "share", in CIFS terminology is not a property of a file
system (sure, we have the ZFS sharesmb property but I am talking in a
more abstract sense here). A share is just a namespace provider.  Some
shares export the server side namespace (or a subset of it), but some
shares are just names for things like printers, COM ports and named
pipes.

In most CIFS implementations, a share used for regular file I/O is
created not on a filesystem, but on a directory.  The exported
namespace is the sub-tree that starts with that directory node in the
server side namespace.  Access restriction is done through ACLs.  the
CIFS server in other implementations (most notably Microsoft SMB
server and Samba) sit on top on the server side namespace and not
directly on top of filesystems.

With ZFS, it was important that CIFS sharing was a property of the
filesystem so that zfs send and zfs recv recreated the CIFS state.

The coarser granularity of sharing for ZFS compared to other
implementations is not an issue for us as ZFS encourages creating many
filesystems (creation is very low overhead).

Generally speaking, file security is handled through ACLs.  By
default, file systems are created with permissions that would stop
"accidental sharing".  An administrator has to make explicit ACL
changes in order to allow users access. If administrators specifically
not want a sub-filesystem shared, then that's what they get by
default.  The namespace is shared but innaccesible.  Current behavior
is not-shared, and innaccesible.

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

As explained above, to users, a CIFS share doesn't look like a
filesystem to them.  CIFS is different then NFS.  NFS exports
filesystems, CIFS exports names.  In fact the most common CIFS setup
I've seen in large Windows shops is one or more CIFS servers that
mount *multiple* filesystems from a SAN (through iSCSI or Fibre) and
create a share on the directory that holds the mounts (so the exported
namespace is backed by multiple filesystems).  (I make no claim that
this is the most common setup -- it's just what I have seen).

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

People don't use our in-kernel CIFS server only for performance but
also for ease of administration and for portability of shares across
filesystem clones and copies (via zfs send and zfs recv).

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

This seems a very interesting idea.

-- 
Aram Hăvărneanu