private group administration

[Robert Locke]

On Fri, 2008-10-17 at 14:00 +0200, Lutz Lange wrote:

> Hi all,
> 
> i was thinking about user creation and group administration. Every user
> gets his own private group when he is created. And the motivation for
> that is to avoid users sharing files with all other users to per default
> right?
> 
> But what if the user wants to change his files with a specific user or
> two? An easy though not well known way to do that would be to push these
> users into the private group. For this to work the user has to be
> Administrator of his private group.

No, you are mixing collaboration with equivalence.  Putting someone in
your private group is more like making them you (based on current
implementation).  "ALL" my files are rw- by my private group.

> 
> ( eg. i'm tux with group tux
>   - root has to make me administrator of my private group :
>   # gpasswd -A tux tux
> 
>   now i can get paul in to my private group
>   tux at somewhere ~> gpasswd -a paul tux
> 
>   or i could set/change my group passwort
>   tux at somewhere ~> gpasswd tux
> 
>   change rights on /home/tux
>   tux at somewhere ~> chmod g+rx .
> 
>   don't forget to check all the other dirs and files for group access
>   tux at somewhere ~> ls -la .
> 
>   you might want to remove group and other bits
>   tux at somewhere ~> chmod g=,o= * .*
> 
>   explicitly open a project dir in /home/tux
>   tux at somewhere ~> mkdir project
>   tux at somewhere ~> chmod g+rwx project
> 
> Writing this i realize that this will only make sense if i use the right
> umask. So lets set it to something more secure, since i might not want
> to change all my files with paul.
> 
>   tux at somewhere ~> vi .bashrc
> 	umask 077
> 
> All right it might not be in my best interest to share something in my
> home dir, or if i do i have to be very careful about the permissions
> there...

So now the private group is not private and is more of a collaborative
group which is no longer "just working" and requiring the user to make a
bunch of caveats....  Changing the umask now breaks the way we "teach"
to do collaboration which takes advantage of the umask 0002 and uses
SGID to cause the collaborative group to be inherited from the directory
rather than the "primary/private" group of the process.  A slippery
slope....

Just use ACLs.  They are turned on by default by anaconda on our ext3
filesystems now through the filesystem superblock.

> 
> But i still thinks a user should be in control of his private group.
> )

Well, I don't have a good argument as to why a user should not be able
to administer their own private group, but still believe your "case
study" is better served by ACLs....

> 
> But he is not. This has to be set explicitly by the entity that creates
> the user. I wonder what the reasoning is/was behind that.
> 
> Why is a user not made administrator of his private group per default?
> 
> Cheers
> Lutz

--Rob