generic ACL stuff
Cole, Timothy D.
timothy_d_cole at md.northgrum.com
Wed Nov 3 17:52:13 GMT 1999
> -----Original Message-----
> From: Jeremy Allison [SMTP:jallison at cthulhu.engr.sgi.com]
> Sent: Tuesday, November 02, 1999 13:47
> To: Cole, Timothy D.; Samba technical
> Cc: 'Marc Jacobsen'; 'jallison at cthulhu.engr.sgi.com';
> tridge at linuxcare.com
> Subject: Re: generic ACL stuff
> The second comment is a bit more on the design. If we
> look at what we're trying to do here, we are attempting
> to reversibly map NT ACLs into any one of a number of
> different disk ACL representations.
Enh, from my perspective, we're trying to do just the opposite: map
native ACLs into NT ACLs. Unfortunately, no matter how you do it, the
transformation is nontrivial and not fully reversible.
> Now converting to an intermediate representation is a
> good idea for a set of utility functions to have, as most
> of the underlying disk ACLs map very well into this
> intermediate representation. However, unless the
> intermediate representation is a complete superset of
> NT ACLs, then in converting to this representation we
> are potentially losing NT ACL information.
That can't really be helped; you're going to lose NT ACL information
in any case, as the underlying representation is not going to be capable of
fully representing an arbitrary NT ACL anyway.
> I would prefer that the vectored ACL functions take an
> NT ACL representation in the (*set)() function and return
> an NT ACL representation in the (*get)() function. The mapping
> between the NT ACL and the internal representation should
> not (IMHO) be seen in the nttrans.c code in Samba, but
> should be an internal implementation detail of the vectored functions.
I don't think the mapping belongs in nttrans.c either, but
realistically, I don't think the vectored functions should deal in NT ACLs.
Writing mappings for n schemes to NT ACLs, rather than one (generic)
scheme to NT ACLs, is going to be more of a pain with regard to maintainence
and keeping consistent semantics between underlying schemes.
Additionally, although it is unlikely, if we ever wanted to support
any other client-side ACL representations, we don't want to design ourselves
into a corner by using NT ACLs in the public interface to the ACL backends.
> Now we can still use all the work on the intermediate representation
> functions by providing the nt_to_acl() and acl_to_nt() and
> associated functions as helper functions that may be called
> by the vectored code internally, I just don't think they
> should be at the Samba nttrans.c level.
Again, I agree that no mapping stuff really belongs in nttrans.c,
but I don't think mixing the underlying OS abstraction and the abstractions
used for NT clients is really appropriate from a design perspective.
> I think Luke will agree with me here, as it is definately
> his dream to be able to directly access the NT ACLs on
> an NTFS partition mounted under a Linux box via Samba.
> Preserving the NT ACLs at the vectored code interface
> would allow this to be done, using the intermediate
> representation would make this more difficult.
Luke and I talked about this before on the ML, and that was what
actually prompted me to remove SIDs from the original ACL interface I
designed. If you can deal directly in NT ACLs, you don't need to do any
mapping anyway. The design I had in mind when writing the current acl.c
stuff was something like (apologies to those using proportional fonts):
| nt_acl.c |
| nt_acl_get() |
| nt_acl_set() |
| | acl.c |
| | |
*NTFS* *native fs*
The acl.c interface's primary purpose here is to abstract the
underlying ACL representation, rather than to provide a mechanism for
manipulating NT ACLs.
I think forcing NT ACLs down into the acl.c layer would only hurt
matters, and make support for NT ACLs on NTFS volumes and other client ACL
schemes more convoluted.
> Please let me know what you think,
> Buying an operating system without source is like buying
> a self-assembly Space Shuttle with no instructions.
More information about the samba-technical