ACL / SD support

[John E. Malmberg]

Michael Stockman <pgmtekn-micke at algonet.se> wrote:
>
> 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.

I would recommend representing the HIDDEN, READONLY, and SYSTEM attributes
as one of these special meaning values.

I noted in earlier post (SURS thread) that mapping the READONLY attribute to
the UID based protection has problems if you allow a user to toggle it to
allow writing to the file.  Representing this as a special identity solves
this problem, while adding another, in this case, that the host system will
not neccessarily honor it.


The reporting of the ARCHIVE bit should be done by a platform dependent
routine so that it accurately represent the backup state of the file.
Setting the archive bit would have a similar routine, for those platforms
that it makes sense.  A smb.conf option that specifies if a non-root user is
allowed to change the ARCHIVE bit may also be desired.

If it is desired to have the state of the following attributes reported and
or updated from a Windows system, then they can also be represented as
special meaning values:

sticky, setuid, setgid, manditory locking, append only, etc...

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

A default protection and inheritance type is needed.  This is implemented in
NT 4.0 SP4.  The commands to display and manipulate this are in W2K or a
patch kit for NT 4.0.

What should the behavior be on host platforms that support ACLs natively?

It would seem that the code would need to be customized for many platforms.


For the host systems that do not support ACLs:

Where will this information be stored?

What happens to the Security Descriptor information when a file is deleted
on the host operating system?

How does the Security Descriptor information get propagated to a new version
of a file when using a native UNIX utility such as VI or EMACS?


-John
wb8tyw at qsl.net