[Bug 253096] Re: pam_umask.so not called in /etc/pam.d/common-session{, -noninteractive}

[ceg]

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
Foundations Bugs, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/253096

Title:
  pam_umask.so not called in /etc/pam.d/common-session{,-noninteractive}

Status in “pam” package in Ubuntu:
  Fix Committed

Bug description:
  The pam_umask.so module determines the umask (from system and user
  config files) and sets it for users accordingly.

  from /etc/login.defs:
  # the use of pam_umask is recommended as the solution which
  # catches all these cases on PAM-enabled systems.

  The umask itself should not be set in /etc/pam.d/common-account, but
  pam_umask needs to be called from there.

  The system's default UMASK remains in /etc/login.defs, setting it in
  common-account would override login.defs *and* any user specific
  configs in gecos fields, see man pam_umask.

  The option "usergroups" is neccessary to have pam_umask check if the
  user has a private user group and re-enables appropriate group
  permission setting for save and easy user collaboration (Info in Bug
  #252351).

  The line needed to call pam_umask in /etc/pam.d/common-account is:
  session optional pam_umask.so usergroups

  (This reflects the settings that are in /etc/login.defs, but have not
  been working since pam broke it.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/253096/+subscriptions