ACL / SD support
Luke Kenneth Casson Leighton
lkcl at samba.org
Sun Feb 13 20:01:25 GMT 2000
> 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;
}
More information about the samba-technical
mailing list