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

[Deano]

I think this sound like an excellent idea.

Deano

-----Original Message-----
From: Aram Hăvărneanu [mailto:aram.h at mgk.ro] 
Sent: 14 January 2011 22:30
To: illumos-dev
Subject: [illumos-Developer] RFE 604: Proposal to allow CIFS server to traverse mount points

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