generic ACL interface (RFC)
Luke Kenneth Casson Leighton
lkcl at switchboard.net
Thu Jul 29 17:59:49 GMT 1999
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
> 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!
More information about the samba-technical