The story behind UPG and umask.
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
Reply to: