generic ACL interface (RFC)

[Luke Kenneth Casson Leighton]

On Thu, 29 Jul 1999, Cole, Timothy D. wrote:

> > -----Original Message-----
> > From:	Luke Kenneth Casson Leighton [SMTP:lkcl at switchboard.net]
> > Sent:	Thursday, July 29, 1999 12:48
> > To:	Multiple recipients of list SAMBA-TECHNICAL
> > Subject:	RE: generic ACL interface (RFC)
> > 
> > hmmm, i see the light.  you'd have to ignore that capability in HP/UX ACLs
> > or map to every single group manually or implicitly.  this ACL would
> > certainly have...
> > 
> > ummm.... what _exactly_ is meant by "user x has read/write access when in
> > group Y"??????
> > 
> 	To rephrase, any processes owned by user x that also have group y
> associated with them have read/write access.

how can group "y" be "associated" with a process [owned by user x]?
 
> > you mean, the HP/UX designers intended users to be moved
> > from group to group
> > 
> 	In Unix (Unix in general, not just HP-UX), users aren't actually
> "in" groups -- /etc/group and other such databases merely indicate the
> "groups" that are to be associated with the user's login process when it is
> created.  (see initgroups(3))
> 
> 	To put it another way, users are not members of Unix groups,
> individual processes are.

*sigh*...  ok.... hmmm... it's different in nt: processes inherit security
contexts, but the security context contains a single SID (methinks...)
which can represent SYSTEM, user, group, alias etc.

> > and ACLs to change meaning / take this into
> > account?????
> > 
> 	They don't change meaning, per se.  The model being what it is,
> checking both a process' ownership and its group membership is not
> unreasonable.
> 
> 	The Unix approach to groups makes sense when taken together with its
> treatment of all other process state.  Very nearly all aspects of a process'
> state (working directory, open files, ownership and group membership) are
> inherited from the process's parent, and cannot be changed by outside
> processes (even those owned by the superuser).  Environments in which
> processes can influence each other's internal state (and in particular
> privileges) are much more difficult to secure.  (for an extreme example,
> witness the abuses of CreateRemoteThread() under Win32)

never used it, never want to. :)

thanks for the insight.  see, i knew you knew more about the unix security 
model / workings than i!