generic ACL stuff

[Cole, Timothy D.]

> -----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):

	           _________
	          |nttrans.c|
	          |_________|
	               |
	         ______v_______
	        |   nt_acl.c   |
	        |              |
	        | nt_acl_get() |
	        | nt_acl_set() |
	        |______________|
	         |NTFS?       |native?
	         |        ____v____
	         |       |  acl.c  |
	         |       |         |
	         |       |acl_get()|
	         |       |acl_set()|
	         |       |_________|
	         |            |
	         |      ______v_______
	         |     |acl_<scheme>.c|
	         |     |______________|
	         |            |
	         v            v
	      *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,
> 
> Cheers,
> 
> 	Jeremy.
> 
> -- 
> --------------------------------------------------------
> Buying an operating system without source is like buying
> a self-assembly Space Shuttle with no instructions.
> --------------------------------------------------------