Comment 5 for bug 253096

> The example came from the pam_umask man page, maybe I had some typo.

Oh, sorry; I was apparently looking at an old, superseded pam_umask module in the archive, and hadn't remembered that there's now a pam_umask module included in Linux-PAM.

The manpage says this about the 'usergroups' option:

          If the user is not root, and the user ID is equal to the group ID,
          and the username is the same as primary group name, the umask group
          bits are set to be the same as owner bits (examples: 022 -> 002, 077
          -> 007).

This would result in inconsistent umask settings anyway, because there is no guarantee that the gid of a usergroup will match the uid of the user: some users would get 022, others would get 002. So that would need to be fixed for Ubuntu use, and I don't know that this is a change that would be accepted upstream since other distros seem to have differing expectations for usergroups.

> There is some history why this bug should be fixed. It is a regression that is now easy to fix.

It is not a regression within Ubuntu; there has never been a non-PAM release of Ubuntu, and Debian has been using PAM for 9 years. From this perspective, changing the system default umask would be a regression, because many users today have no idea what a umask is yet may be dependent on this setting for their security - for instance, when creating files in sgid directories that they /don't/ intend to be readable by the group. These subtle semantic changes are such that I don't think it would ever be a good idea to relax the default umask.

I am setting the bug state back to 'new', in any case, because I'm no longer sure that session umasks are set correctly in all cases since some sessions don't involve spawning a login shell.