Hi, am glad UPGs and the default umask finally got some momentum. Technical issues below.
For anybody who has any doubt about UPGs or thinks it's insecure, here is a explanation snippet from [0]: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (This should be true, but still needs the fixes from below.) It is easy for multiple users to collaborate on debian systems. Just keep in mind that access permission to a file always depends on the permissions of the file itself AND the permissions of the directory path to it. By default files are readable for whoever has access to them, just as paper files are, but not writeable. If you don't want others to read your files, keep them in a private/ subdirectory. The path into your home directory is not restricted, just as the path others can take to ring your bell at home is not restricted. As a matter of fact you may post some files on your door, for others or to read. For example many programs read config files that you deposit in your home path. Besides, other users can drop files (for you personally) in your ~/incomming/ directory. All this can work because the primary group of each user is set to a private user group (UPG) by default. (A group without any mentioned members in /etc/group, named equal to the user.) This allows to grant write permissions to created files for the group by default. No one exept the owning user will be able to write to the file. Exept that is, if it has been created in a group directory... Group directories (directories with the set-group-id flag set) are special places (that again all users are able to visit) where the members of the group that owns the directory can write files in it. According to the set-group-id flag files created in the group directory will belong to the creating user who wrote the file and to the group *the directory belongs to*. The result is that all members of the group can work on the files in a groupdir of theirs. Other than that, group directories work just like home directories. So if a file for example should be readable only by group members, again put it into a private subdirectory. Group directories may be set up by regular users in their home directories, or by the system administrator or (automatically) by the addgroup command under /home/group. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It seems things quite used to work before PAM was introduced while it didn't support any UPG detection at that time, but now pam_umask is here to help us out and we get the chance to fix it better then before. Some additions I'd like to make: * Things like ssh can and should keep requiring private permissions! Instead tools/scripts should be patched to adequately write these files with the umask set accordingly. (If they are not already, simply by having them manually override the default umask.) According to [1,2] a UPG is identifiable by 1) A group of the same name as the username 2) A special case is true: The group is set as the main group of the user (in /etc/passwd) while the user is NOT added to his group in /etc/groups. 3) UID==GID was questioned to be a requrement, probably because it was seen that it isn't be enforced, but it can be of great help if you are looking at a filesystem (removable drive) without knowing the corresponding passwd/groups file. So maybe it is sane that UID==GID is a requirement, and its only an adduser bug when it does not skip IDs that have been taken by non UPG groups when creating users, and thus does not deliver that requirement. With 2) you can still see that the group has been set up as a UPG even if additional users are added to the group. Explicitly it allows to detect that: A) Those users were added intentionally to the UPG and the umask should still be set to 002. (In general you create separate groups to enable user collaboration on UPG systems, so tools may very well give a warning/hint about it if you try to add a user to a UPG.) B) The group can be deleted if the user is deleted. Kind regards, Christian [0]https://wiki.ubuntu.com/MultiUserManagement [1]https://bugs.launchpad.net/gst/+bug/488158 [2]http://lists.alioth.debian.org/pipermail/adduser-devel/2008-February/003161.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100525220935.201d11b8c.gatzeme...@tu-bs.de@tu-bs.de