ACL / SD support

[Michael Stockman]

Hello,

Just though I'd drop a status report and see how you react. I have
started with the ACL part, and would be happy to proceed also with the
SD part in a short while (where I can store data that __really__ is
necessary and __really__ don't belong in an ACL). I'm also very
pleased that this implmentation so far have got constant size
structured which allow size to be predicted only knowing the number of
ACEs.

Basic data entities:
id_entity
  type
  union of uid / gid / special
This is a identifier that contains either an uid, a gid or an internal
special meaning value. Currently there are 4 special meaning values:
None, Everyone, Owner and Group. Should you want any others, please
say.
If there is massive support for SIDs instead I'll change this, but I'd
rather not.

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

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
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
future ACL versions will be able to contain at least the same
information that today's can. There will be an str_to_acl function,
mainly for testing/debugging purposes which have a format:
"[@!]nnn([ttt:][+]rrr[:[-]rrr][:fff])*". nnn is determined by prefix
where no -> uid, @ -> gid and ! -> special. ttt is type, rrr are
rights where + (default) are allow rights and - are deny rights. fff
are ACE flags.
Example of principle (actual numbers and letters will differ):
"0(a:0007) @0(a:0005) !3(d:-0007)"
This could mean an ACL with these ACEs:
ACE  uid 0
     type a (access)
     allow mask 7 (rwx)
ACE  gid 0
     type a (access)
     allow mask 5 (rx)
ACE  special 3 (Everyone)
     type d (audit)
     deny mask 7 (rwx) (audit failed attempts for these rights)
A later, more advanced version could lookup user, group and special
names and allow them to be used instead of the number. The permissions
are numeric because they are (in NT) highly dependant on whish kind of
object the ACL is associated with.

Access evaluation:
The ACL gets a mask of desired bits and a list of id_entities to check
for. It traverses the list of ACEs in an ordered fashion and for each
ACE check if it applies, both type and id_entity. If it applies, deny
mask is checked and if any of the desired bits is denied: fails.
Should it not have failed, allow bits are collected and when all bits
in the desired mask have been collected: succeeds. It is a failure to
reach the end of the ACEs without all allow bits to have been
collected.
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.

Audit/alarm evaluation:
Audit and alarm evaluation I'm currently not going to implement but
would be trivial if a proper logging/alarm system is available. Andy,
this might be something you want?

Best regards
  Michael Stockman
  pgmtekn-micke at algonet.se