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@somewhere ~> gpasswd -a paul tux > > or i could set/change my group passwort > tux@somewhere ~> gpasswd tux > > change rights on /home/tux > tux@somewhere ~> chmod g+rx . > > don't forget to check all the other dirs and files for group access > tux@somewhere ~> ls -la . > > you might want to remove group and other bits > tux@somewhere ~> chmod g=,o= * .* > > explicitly open a project dir in /home/tux > tux@somewhere ~> mkdir project > tux@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@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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
