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

[Eric Schrock]

On Thu, Jan 20, 2011 at 3:17 PM, Aram Hăvărneanu <aram.h at mgk.ro> wrote:
>
>
> Case-insensitivity matching is required to avoid application confusion
> on the client side.  Applications expect either a case-sensitive
> namespace or a case-insensitive one (most Windows Application expect a
> case-insensitive namespace).  Applications are confused when case
> sensitivity is an arbitrary matter.
>
> ACLs are required for the same reason as case-sensitivity and also for
> administrative purposes. With CIFS it is common and expected that ACLs
> are set from the client side. Either they are set by the applications
> themselves, or administrators set them with Windows tools.  We make a
> promise that ACLs either exist or do now, and to keep this promise we
> need to have consistent behavior in all backing file systems.


So the answer is that it does not break programmatic correctness (i.e.
operations don't fail at the protocol level), but users and applications
will be confused.  This should be explicitly stated in the spec.

So why is it OK that a parent filesystem supports system attributes but a
child filesystem does not?  From the assertions above (correctness,
confusion, expectations), it would seem that having one file that could have
the archive bit set but a subdirectory with one that couldn't would be a bad
thing.

It still seems to me that this should be configurable.  There are many users
who would prefer to access to their data in a degraded form than no access
at all.

At traversal time.


Please update the spec to indicate this.


> > The proposal seems to overly simplify the SMB model (the relationship is
> not
> > actually 1:1),
>
> I don't think the proposal simplifies the SMB model, this memo
> proposes changing what happens at traversal time.  There are other
> ways of creating SMB shares besides the sharesmb property
> (sharemgr(1M), MMC, etc) and those would continue to work as they do
> now.


Right.  The spec made the incorrect statement that filesystems and shares
have a 1:1 relationship, which was the source of much of my confusion.  It
would be good to explain this in more detail before diving into sharesmb
semantics.

> and I'm not sure I understand the fixation on 'sharesmb' as
> > the primary mechanism for communicating these semantics.
>
> sharesmb creates a share, it was never a mechanism for controlling
> access (although many people interpreted sharesmb=off that way).
> While sharesmb=on behavior was explicitly documented, sharesmb=off
> behavior was never explained.  This proposal doesn't try to make
> sharesmb the primary mechanism for communicating CIFS semantics, on
> the contrary, it tries to document what sharesmb=off does and doesn't
> do.  The proposal is that sharesmb=off doesn't do anything and that
> it's possible to have (parts of) a filesystem exported via CIFS by
> other means.
>

OK, that makes sense to me.  Perhaps it was some of the follow-on thread
that confused the issue for me.  Based on that discussion and my own
comments, it seems there is an opportunity to have a sharemgr(1M) option
(which may or may not be exported over sharesmb) of something like
traverse=<on|off|restricted>, with "restricted" being the default.

I definitely wouldn't change the ZFS-level inheritance semantics of
sharesmb, as that could break existing deployments, and makes the assumption
that child filesystems are necessarily mounted beneath the parent filesystem
(an especially broken concept when the parent serves as a container and is
not explicitly mounted).  One possibility would be to have something like
"sharesmb=root", which has the semantics that a share is only instantiated
if the property is set locally.


> Correct, this memo is concerned only with the issue of traversing
> mounts, and while doing this touches the issue of what sharesmb
> actually means.  It's not concerned with alternative sharing methods.
> Those work as before.
>

Please make this more explicit in the spec.


> > What happens if I connect
> > over MMC and create a share beneath a sub-filesystem?  Will the SMB
> server
> > be smart enough to traverse all sub-mounts and load any sub-directory
> shares
> > such that they can be exported properly to administrative clients?
>
> I am not sure what you mean by properly in this context, but yes, they
> are exported.
>

What I mean is this:

1. Create an SMB share "PARENT" at /export/parent
2. Create a child filesystem at /export/parent/child
3. Create an SMB share "CHILD" at /export/parent/child/subdir

Now, when I connect to "PARENT" over MMC, am I able to create and manage
shares within the child filesystem (i.e. the "CHILD" share)?  I'm not an MMC
expert so I don't know how this is presented to the user, but if we're
maintaining the view that this is a single filesystem, it seems like we
necessarily have to be able to create and manage shares within
sub-filesystems.  Can you elaborate on how this works today and what the
user experience will be in the above scenario after your change?

Given the number of comments, I'd like to see an updated spec incorporating
feedback thus far and extend the timer another week.

Thanks,

- Eric

-- 
Eric Schrock, Delphix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.illumos.org/pipermail/developer/attachments/20110121/97078f3e/attachment.html>