NTVFS vs S3 file server

[Michael Adam]

Hi Tridge,

Andrew Tridgell wrote:
> Hi Michael,
> 
> > I see a potential danger with interoperability in heterogenious
> > setups where cifs and nfs are served from the share at the same
> > time and other software might also want to change the permissions.
> > For this case, the acl_xattr module has the mechanism to fall
> > back to the permissions stored in the file system when they have
> > been changed externally with respect to the stored NT ACL. In these
> > mixed environments, the override mode is not an option, imho.
> 
> Actually I think it is in these mixed environments where the override
> mode is most essential.
> 
> If you don't have the override capability then the only way to get
> really accurate NT ACL behaviour is to set the unix file permissions
> very broadly. This for example is what is done in the [xcopy_share] in
> the Samba3 testsuite. If that share is also exported via NFS then that
> means that NFS clients will see these very broad permissions, which is
> potentially dangerous.

Agreed, mapping down to file system acls usually means we have a
lossy mapping, and when we want to ensure that users allowed to
write by the NT ACL are also allowed to write by the file system,
then usually we need to make that mapping generous. And this
means that NFS users might be granted too much access. => danger

> The ideal for mixed environments is to use a "last ACL set wins"
> model. If the last ACL set was a NT ACL, then use the NT ACL, and
> ideally you would provide a mapping to posix ACLs during the setting of
> the NT ACL (so posix apps see the mapped ACL). If the last ACL set was a
> posix ACL then use that. You can do this by storing a hash of the posix
> ACL in the NT ACL, allowing for detection of posix ACL changes.

This is precisely what the acl_xattr and acl_tdb modules do.
Maybe I did not put that explicitly enough. The danger of the
mapping giving too much access rights to unix/nfs users is still
there.

> This is largely orthogonal to the "raceless override" mechanism
> however. Before we had the pvfs_sys.c code we defaulted the NT ACL
> override to off as it wasn't safe. After the pvfs_sys code was added it
> defaulted to on, as I think it is a big benefit for many users,
> particularly for shares that tend to use complex ACLs (such as sysvol,
> with delegated administrative control).

I need to think about whether and how the override mechanism
could be combined with a more restrictive mapping to give a
better interop mode.

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20111208/63d61670/attachment.pgp>