generic ACL interface (RFC)

[David Collier-Brown]

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
		a subset of Unix ACLs
	and have
		a mapping (not necessarily a good one) to unix
		permissions.

	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. In fact, I'd want a
anion, lest I accidentally set user_id and group_sid at the same time
(ok, I'm klutzy (;-))

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

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?

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). If not, we can't present it
to NT, although we can recognize it and honor it within Samba.


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.

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