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

[Aram Hăvărneanu]

Eric Schrock <eric.schrock at delphix.com> wrote:
> You have called out case-insensitivity as a reason to disallow traversal,
> but there are other VFS-level features that the SMB server relies on that
> may be different between systems, such as support for system attributes or
> UTF-only enforcement.  Is the intent to disallow traversal through all such
> changes?

No, not all features are critical.

> Is disallowing this due to programmatic necessity, or to avoid
> user confusion?

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.

> If the former, it would be good to explain exactly the
> scenarios in which this breaks down.

I hope to have answered your question, if I have not, I can certainly
add a more in-depth explanation.

> The proposal is also not explicit in when this check
> is enforced.  Is it at share time (seems like a bad idea, considering the
> set of filesystems can change dynamically), or at traversal time?

Traversal time.

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

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

This is *already* possible with sharemgr(1M).  The fact that you can
share a filesystem that has sharesmb=off with sharemgr(1M) means
people should not have used sharesmb as a security mechanism.

This memo proposes making all this facts documented explicitly.

> Each filesystem
> can have multiple shares within it (which can even be created through MMC),
> and the 'sharesmb' property, while convenient, doesn't really reflect the
> full suite of functionality one may want to export.

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.

> 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 is
> the sharemgr(1M) view of this state?

It is just like when you create a share for that directory manually,
on the server side, because this is what really happens.

Thanks,

-- 
Aram Hăvărneanu