ACL / SD support

[Luke Kenneth Casson Leighton]

john, i think this acl implementation is being considered as an internal
samba implementation and won't ever be dropped to disk.  it therefore
serves as the interface between NT security descriptors and the underlying
filesystem.

exactly why this is being considered, i really don't know, particularly as
samba will not be expected to support anything other than NT security
descriptors.

i mean, why map to something that's either a subset or a superset of the
security model we're trying to implement?  i mean, if it's a subset,
you're dropping permissions.  if it's a superset, you're wasting
permissions.

and then there's the issue of if it doesn't support SIDs, that's _two_
overheads to convert from SIDs to posix and back, if the target filesystem
supports SIDs.

i'm not against this effort, i just... don't really get it.  i'm happy to
contribute with comments, both critical and supportive.


On Mon, 14 Feb 2000, John E. Malmberg wrote:

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

<a href="mailto:lkcl at samba.org" > Luke Kenneth Casson Leighton    </a>
<a href="http://cb1.com/~lkcl"  > Samba and Network Development   </a>
<a href="http://samba.org"      > Samba Web site                  </a>
<a href="http://www.iss.net"    > Internet Security Systems, Inc. </a>
<a href="http://mcp.com"        > Macmillan Technical Publishing  </a>
 
ISBN1578701503 DCE/RPC over SMB: Samba and Windows NT Domain Internals