ACL / SD support

[Luke Kenneth Casson Leighton]

> ACE
>   id
>   flags
>   type
>   allow_mask
>   deny_mask
> Contains one allow mask and one deny mask for an entity. This is
> different from how NT does if (different type for allow ACEs and deny
> ACEs), and forces the definition that a deny mask is evaluated before
> the allow mask. This decision is made to allow any rwxrwxrwx
> permission to be mapped to 3 ACEs, which I think would be the obvious
> thing to do.

it may be obvious, however it is a deliberate design restriction that is
unnecessary, if you ask me.

> Flags contains some inheritance stuff. Type specifies if the ACE is
> access controlling, audit controlling or alarm controlling (not
> currently implemented in NT I believe).
> Should we for example want time control, time fields can be added and
> a flag to say timing is in effect. I would rather not have several ACE
> structures.


... if you have a "type", what is wrong with that?  i have tried several
times in samba code to take an initial approach where is simply added
extra structures to a union or just extra members to a structure.

i alway, always, end up replacing it with a "type", void*, size (if not
using malloc) and if no size parameter i have a pointer-to-free function:

it depends on whether you want to static-store the data or dynamic-store
the data.  obviously, you can't have a free_function for off-line storage
of a dat structure (read/write to disk).

{
	enum type;
	int size;
	void* data;
	(void) (*free_function)(void);
}


> ACL
>   ace_count
>   ACEs
> Contains the ACEs and a count of them.
> There is no sence of ACL revision, the ACL will contain all data and

uh...

> thus the format (revision) is added when the ACL is mapped to NT
> format. I would rather see that internal ACLs that must be stored on
> disk are stored in a revision independent format. After all, all

uh... 

you're locking yourself into an out-of-date system, before you've even
started.   a "revision" number allows you to make the kinds of decisions
to continue supporting what will become legacy systems, whilst still be
able to move forward on more dramatic designs.

the ugo+rwx system is a classic example.  noone can get away from it
because there's no room to expand it without a total redesign.

> I have already descided not to include override facilities here (like
> root) and think it is up to the various places where ACLs is checked
> to define their own (possibly shared) override ACL, if that
> functionality is desired.


yes, that's good to have - you want the ACL to be kept simple.  adding
"poverrode" facilities complicates the design.  if you _want_ override
facilities it should be granted to an ACL-controlled set of users, anyway!

{
	ACL *user_perms;
	ACL *override_perms;
}