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

[ceg]

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.)

[ceg (ceg)]

Oh, the problem with the current state is that umask is set all over the place in shell config files, xsessions, and do not work for ssh logins for example.

[Steve Langasek (vorlon)]

Thank you for taking the time to report this bug and help to improve Ubuntu.

There is nothing dynamic about what umask value that should be used for a given user, and there are already well-established means of setting the umask for a session (which will only be further confused if we add another method on top of that), so this is not a change that Ubuntu should adopt. It's possible that there are places where a wrong umask is being set by default; those would be bugs, and should be fixed, but they are not bugs in pam, and should not be worked around by adding complexity to the default pam config.

Also, I cannot corroborate your statement that setting umasks by the usual method doesn't work for login sessions. It certainly does for me. You may want to provide more detail about your use case.

The example syntax you gave is also invalid. The pam_umask module in intrepid does not recognize a 'usergroups' option.

[ceg (ceg)]

Hello Steve,
thank you for improving ubuntu.

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

There is some history why this bug should be fixed. It is a regression that is now easy to fix.
Before pam was introduced "login" provided the central point to set the UMASK value in login.defs and also containded the USERGROUPS_ENAB checking feature.

The switch to pam was made before pam supported this functionality. Since umask is an important parameter that people need to have set, they began to set umask in shell rc scripts, xsessions, ssh_config, some display mangers even hardcoded the umask etc. (And some of this had to be done to face the regression in day to day use.)

Finaly pam_umask.so reintroduced the functionality in pam and has now been merged from its own package (pam-umask) into the libpam-modules upstream. From the pam-umask package description: This package is useful to ensure that users' umasks are set consistently whether their session is initiated by login, SSH, a display manager for the X Window System, or some other means.

[ceg (ceg)]

FYI here is a summary of a Sep 2005 discussion in debian, by now it may be added that, as pam_umask supports the "usergroups" feature, it is no longer neccessary to set the umask to 002 for all users, with pam_umask's "usergroups" feature it will check if users are in a private primary user group.

(Debian/Ubuntu has allways used private user groups by default, the switch to pam only broke adequate umask adjustment. Those that are not familiar with the merrits of private user groups for collaborating with other users may have a look at explanation supplied with Bug #252351)

It might be desireable to supply a patch to pam_umask to not only fetch UMASK but also the USERGROUPS_ENAB setting from login.defs (or /etc/default/login), then "usergroups" does not have to be set in common-session.

Here is the report about the related debian discussion:

Christian Perrier <********@debian.org> wrote:
>
>(adding the shadow maintainers list to the CC, and therefore keeping a
>whole citation, sorry fot this)
>
>> Summary for technical comittee: setting the umask
>>
>> Inconsistent umask settings; user private groups concept requires umask 002 to
>> work.
>> Relates to #248140 #248150 #314539
>>
>>
>> Please successively reasign to base-files (and other packages containing umask
>> settings), login and libpam-umask packages to resolve the situation.
>>
>>
>> Debian ships defaulting to put newly created users into private primary
>> groups. The so called User Private Group (UPG) concept allows easy access
>> right management for users. In sgid group-directories access rights of files
>> can be set correctly automaticly. It is proven to work fine.
>>
>> Even though UPGs are the default in debian, they are not set up to work
>> properly. The umask is currently set at different places and to conflicting
>> values. The result is that the settings to 002 are in most cases not active.
>>
>>
>> CURRENT SITUATION
>>
>> The settings in /etc/login.defs do reflect the use of UPGs and are adjusted to
>> generate the correct umask:
>>
>> # Enable setting of the umask group bits to be the same as owner bits
>> # (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is
>> # the same as gid, and username is the same as the primary group name.
>> #
>> # This also enables userdel to remove user groups if no members exist.
>> #
>> USERGROUPS_ENAB yes
>>
>> However:
>> a) This login.def functionality is not active on systems with PAM (now
>> standard in debian). And the pam_umask funktionality is not part of the base
>> system.
>>
>> b) The umask gets overwritten in shells that source rc files like /etc/profile
>> which ships with an umask line.
>>
>>
>> SUGGESTED SOLUTION
>>
>> 1) remove/comment out any umask settings in all shell configuration files
>> shiped with debian (i.e. /etc/profile) and add a comments
>> that /etc/login.defs or better pam_umask ist the right place for global umask
>> setting.
>>

It might be /etc/default/login (LSB?) now, pam_umask looks at both.
Setting umask in common-session is only to override user specific GECOS settings.

>> 2) In /etc/login.defs correctly move all settings that are overridden by PAM...

[Steve Langasek (vorlon)]

> 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.

[ceg (ceg)]

The wording of man pam_umask seems pretty much the same as what used to be in login.defs before.
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=login.defs.diff;att=1;bug=282822

I have also made the experience that some graphical user managment tools do not keep gids eqal to uids and that tools create subdirecories in the homes, mimiking other OSes behaviour, but /etc/skel is not used for this. The writers of desktop environment tools do not seem to allways follow unix philosophy. I noticed debian policy states: "Packages other than base-passwd must not modify /etc/passwd, /etc/shadow, /etc/group or /etc/gshadow." (http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2)

---

Just as you write, configuring pam_umask to provide unified means to set the umask for all sessions does not yet automatically (re)enhence default permission handling.

If the default umask enables easy usability of permission handling, or does pretty much not support it, it should maybe be less the the result of the shiped pam implementation and adhere to the all time shiped configuration. (USERGROUPS_ENAB yes) Which grants 002 only if it's pretty safe and a feature, many times reported to not work properly and hacked around. (Even though many ubuntu users may have never noticed, and may just think file permissions just allways are like an inflexible pita style thing.)

As the user groups created by default have all the time been private ones, it should be pretty save to let the 022->002 mapping do its work for them. The corner case being of course those that are really using sticky sgid directories without actually figuring out to change the umask. Meaning those that manually change filepermissions every time to be able to collaborate with other users, even when they decide to expicitly save stuff into special group places instead of saving into more private (sub)dirs.

If we find a good name for that behaviour, we could actually provide sticky non-sgid subdirectory examples to publish something readonly within a group.

(Does /home/share/<group>/writings /home/share/<group>/readings compare to /home/<user>/private?)

From the point of the implemented private user groups, if you want that other members of a group can work on a file together with you, they need to be in a group with them and you have to save the file into a special setgid directory, if not keep the file at home, in a private place if you don't want others to be able to read it.

For shared write access you save it under the (sgid) group directory. This seems to be the feature and having to fiddle with file permissions is bugging users.

Private user groups with umask 002 and a nice set of default directories are quite a feature, I would say. They should be save as long as filessystems are not transfered verbatim to systems with other group setups, but then, when transfering filesystems to other machines one allways has to watch for differences in IDs, anyway. All copy processes should honor the umask on the target systems, if not explicitly overridden to preserve permissions and numerical ids.

Maybe I just don't understand that much of the private user group approach that I see ...

[ceg (ceg)]

Please include a pam-auth-profile to support the user private group theme.

So that a debconf setting will put the line
"session optional pam_umask.so usergroups"
into the common-session config.

[ceg (ceg)]

The following wiki page now contains more information and ties together related bugs.
 https://wiki.ubuntu.com/MultiUserManagement

[ceg (ceg)]

forget comment #7

Properly fixing this issue of no central, consistent and tunable umask setting in debian and ubuntu systems is now only a matter of adding the line "session optional pam_umask.so usergroups" to /etc/pam.d/common-account.

Thanks to pam_umask and its inclusion, and the all the efforts to remove umask settings from all shipped shell rc files.

If you review the attached patch, it should add pam_umask to common-account.

[Steve Langasek (vorlon)]

No, session modules don't get called from /etc/pam.d/common-account. That would need to go in /etc/pam.d/common-session{,-noninteractive}.

(I have not otherwise reviewed the proposed patch for suitability.)

[ceg (ceg)]

Forgot to mention the reason I changed it to common-account is that /etc/pam.d/sudo does not include common-session. This might be OK if sudo is not considered to open a session. But having a different umask using sudo would again not be expected and lead to wrong permissions etc.

Maybe it is more appropriate to fix sudo to include common-session{,-noninteractive}?

This second patch targets common-session{,-noninteractive}.

[ceg (ceg)]

The issue that sudo's pam config is not including the common-session configuration is now tracked separately Bug #549172
and the /etc/pam.d/common-session{,-noninteractive} patch would be the right seed to call pam_umask.

[Martin Pitt (pitti)]

Attached branch now adds pam_umask. I also tested that this works on upgrade.

I did not add "usergroup", as this will be handled by parsing /etc/login.defs for USERGROUP_ENAB, see https://blueprints.launchpad.net/ubuntu/+spec/umask-to-0002

[ceg (ceg)]

May you also consider the secure UPG detection checks 2) and 3) in your branch?

2) and 3) where summarized here:
http://lists.debian.org/debian-devel/2010/05/msg00887.html
and the discussion followed:
http://lists.debian.org/debian-devel/2010/05/msg01069.html

[Martin Pitt (pitti)]

@ceg: My branch doesn't change the pam_umask checks, it only enables pam_umask itself and the usergroups feature.

TBH I don't quite understand http://lists.debian.org/debian-devel/2010/05/msg01069.html: 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/passwd?

[ceg (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.

[Launchpad Janitor (janitor)]

This bug was fixed in the package pam - 1.1.3-1ubuntu3

---------------
pam (1.1.3-1ubuntu3) oneiric; urgency=low

  [ Steve Langasek ]
  * debian/patches/pam_motd-legal-notice: use pam_modutil_gain/drop_priv
    common helper functions, instead of hand-rolled uid-setting code.

  [ Martin Pitt ]
  * debian/local/common-session{,-noninteractive}: Enable pam_umask by
    default, now that the umask setting is gone from /etc/profile.
    (LP: #253096, UbuntuSpec:umask-to-0002)
  * debian/local/pam-auth-update: Add the new md5sum of above files.
  * Add debian/patches-applied/pam_umask_usergroups_from_login.defs.patch:
    Deprecate pam_unix' explicit "usergroups" option and instead read it from
    /etc/login.def's "USERGROUP_ENAB" option if umask is only defined there.
    This restores compatibility with the pre-PAM behaviour of login.
    (Closes: #583958)
 -- Martin Pitt <email address hidden> Fri, 24 Jun 2011 11:07:57 +0200