The "usergroup" checks of pam_umask should be more secure against false
privilege escalation.
> When /etc/passwd specifies my UPG as my primary group, why does it
matter if my own user is added to my group in [/etc/group]?
That is convention 2) for UPGs.
For the system itself there should be no direct effect, as it should work just
as well without separate groups file. However, with the convention that a UPG
will be set as primary group but not added to the user in the group file (while
all other groups are added), you make the group identifiable as an UPG group
even
if additional users are added to the group.
That allows to detect that:
A) Only additional users were added (intentionally) to the UPG, and the umask
should still be relaxed to xxy. (In general, you'd 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. However, this if very helpful, for example, if one user uses
sub-users for different tasks.)
B) The group can be deleted if the user is deleted.
Specificly, debian's adduser command uses this convention to detect if it can
delete the UPG together with the user, if the user is deleted.
Unfortunately, debian's adduser command has a bug that keeps it from ensuring
the convention 3).
With regular groups added to the system, it just takes the next free UID, which
is not equal to the next free GID anymore. Instead it should seek for the next
free pair of GUI==UID, possibly even based on a hash to increase the chance of
of a unique username to have the same numerical IDs accross different systems.
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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/253096
Title:
pam_umask.so not called in /etc/pam.d/common-session{,-noninteractive}
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/253096/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs