generic ACL interface (RFC)

[Cole, Timothy D.]

> -----Original Message-----
> From:	David Collier-Brown [SMTP:davecb at canada.sun.com]
> Sent:	Wednesday, July 28, 1999 8:20
> To:	Cole, Timothy D.
> Cc:	samba-technical at samba.org
> Subject:	Re: generic ACL interface (RFC)
> 
> Tim wrote:
> | Here's a very early shot at a header file for a generic internal ACL
> | interface for SAMBA.  I _think_ the representation is general enough
> | to cover all of the major Unix ACL schemes without losing
> information
> | (well, at least POSIX/Solaris, HP-UX and AFS [I think]).
> 
> 	I think you covered posix & slolaris ok, but I'd best
> 	ask the meta-question: what's the requirement?
> 
> 	I'm going to initially assume that you're planning to
> 	implement NT ACLs on Unix, using the native dac mechanisms
> 	of the OS.  If so, the results need to be
> 		a subset of NT
> 
	I suppose... although since this is really intended to be an
intermediate representation, you may want to hold onto information even if
it can't be presented to the client.

> 		a subset of Unix ACLs
> 
	enh; best be a superset.  otherwise your intermediate representation
ends up throwing out information.

> 	and have
> 		a mapping (not necessarily a good one) to unix
> 		permissions.
> 
	That's (typically) accomplished by the native ACL implementations
themselves.

	Rather than implementing NT ACLs on Unix per se (that's a slightly
different problem), I'm looking at this from the standpoint of exposing the
native Unix ACL mechanism to the client with as little loss of information
as possible.

> 	Addressing the first two only, the meta-questions then become
> 	1) is this enough to be useful to the victim/owner of the
> 	   PC client?
> 	2) is it representable **everywhere**
> 
> 	I'm going to have to throw the second question back at you,
> 	and to the list: can we get there from here?
> 	
> Oversimplifying the struct, we get
> | acl_entry_info {
> |        type ::= { WORLD | USER | GROUP | USERANDGROUP | MASK }
> |        flags ::= { OWNER | GROUP | VALUID | VALGID | VALUSID 
> |		| VALGSID | DEFAULT | UNSUPPORTED }
> |        uid_t user_id;
> |        DOM_SID user_sid;
> |        gid_t group_id;
> |        DOM_SID group_sid;
> |        struct {
> |                allow ::= { EXEC | SEARCH | WRITE | INSERT | READ |
> |			CONTROL | DELETE | REMOVE | LOCK }
> |                deny ::= { same as above }
> |        } perms;
> |}
> 
> Side issue:
> If the flags fully enumerate the types, you can have a union of
> user_id, user_sid, group_id and group_sid.
> 
	You can have any combination of them simultaneously, so a union
wouldn't make sense.

> In fact, I'd want a
> anion, lest I accidentally set user_id and group_sid at the same time
> (ok, I'm klutzy (;-))
> 
	ah, but you might want to.  two scenarios:

	1. as far as having both user and group information, if you're using
HP-UX or something else which can have a user _and_ group for a single ACE,
it's entirely possible that they both might be set

	2. after what Luke said, I'm not sure the SIDs should be in there
anyway.  However, if they are, it's not unreasonable to store both the uid
and its associated SID in the ACE when possible, to avoid excess lookups,
and in cases where an SID may not actually map to a uid.

> Now this can represent a Solaris ACL entry, and present it to a
> PC client in a sane manner.  That makes it a subset in the somewhat
> vague sense I meant. 
> 
> However, I can't represent all the data in a Solaris ACL: CONTROL
> isn't
> implemented, for one thing.  This means that the permission can be
> asked for by the PC, can be represent here, but can't be stored
> in the filesystem.  In the case of control, you could probably 
> make it a constant: "you never|always get control".
> 
	Well, control (set permissions) should probably be forced on for the
file owner, and forced off otherwise.  But since it can't be set, it doesn't
really matter very much.  Really, we have exactly the same situation with
the existing "ACL emulation" -- a lot of the permissions are ignored/thrown
out/interpreted differently.  

	That's probably best.  You can't really implement NT semantics with
most other ACL schemes (or vice versa), so it really just makes sense to
expose what you can of the actual permissions, and let the underlying ACL
implementation worry about their semantics.

	It kind of galls me to not have consistent semantics presented to
the client, but I think the least confusing thing to do is to avoid trying
to "fake" semantics, in situations where you could never do it perfectly.

> What else isn't representable (take ownership, for one)?  If it
> can't be represented, can it be computed from other information
> stored on Unix or created out of whole cloth?
> 
	Probably just ignored, but used as a placeholder for "blank" ACEs,
like it is now.

> Finally, EXEC may not be an NT acl (I don't know: my book is at home
> and I'm not expert enough on NT to know).f not, we can't present it
> to NT, although we can recognize it and honor it within Samba.
> 
	It is in an NT ACL.  NT ACEs contain the following permissions (at
minimum):

	  - read
	  - write (insert)
	  - execute/search
	  - delete (remove)
	  - change permissions (control)
	  - take ownership

> Tim also asks:
> | what should the return values mean here?
> 
> That's more of a convention question.  Personally I like success
> and failure, but that raises the question of how to identify errors.
> Some folks return 0 for success and errno values for errors, so calls
> have to look like 
> 	if (get_acl(fsp,entries, n_entries) == 0) {
> 		do success code
> This is not common in samba source, so it may not be a good idea!
> Perhaps you may want an "int whynot" parameter (;-))
> Alternatively you may want to return the number got, especially if
> it's
> larger than the number asked for.
> 
	I'll have to look at the inferfaces presented in other parts of
Samba some more, I guess.

> --dave
> [I used to be on an interfaces-quality project: feel free to email me
> ]
> -- 
> David Collier-Brown,  | Always do right. This will gratify some people
> 185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
> Willowdale, Ontario   | http://java.science.yorku.ca/~davecb
> Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb at canada.sun.com