generic ACL interface (RFC)

[Cole, Timothy D.]

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

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

	Processes inherit their group memberships from their parent.
Processes can revoke their own group memberships, but they cannot add
themselves to groups unless they are owned by the superuser. (see
setgroups(2))

	(thus, if /etc/group is changed while a user is logged in, the user
must start a new shell using a privileged tool like newgrp(1) (typically
"exec newgrp the_new_group"), as the existing processes' group memberships
will not change)

	Also, it is possible to make a script or a binary "sgid" (g+s,
02000), so that when it is exec()ed, the new process will become a member of
the group if its parent was not already.  (the group will become the new
process' primary group in any case).  Note that only processes already in
the owning group can set the sgid bit on a file, and that changing the
owning group will clear the sgid bit.

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