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

[Garrett D'Amore]

For the record, I think your comments are good Eric, and I totally agree
that we need to extend the timer.. in fact at this point I'd like to
recommend that we just remove the timer -- the timer was intended to
ensure we weren't hamstrung by a lack of feedback.  That's not the case
here, and I think we should keep going until we either achieve
consensus, or reach a point where no further feedback and interactions
are occurring.

Once we reach consensus, I think we can restart a *short* timer to give
anyone else who hasn't participated up to that point a chance to comment
on the final spec, but I think that if there are any such individuals
they should speak up now.

	- Garrett

On Fri, 2011-01-21 at 10:03 -0800, Eric Schrock wrote:
> 
> 
> 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
> 
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer