Comment 4 for bug 253096

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
>> below that comment (i.e. USERGROUPS_ENAB) and vice versa[1]. Set the umask
>> to 002 for the case that libpam-umask is not installed, but point the admin
>> to libpam-umask and the right file for the umask setting.
>>

The historical UMASK 022 may be set (uncommented again) if /etc/default/login is not adopted, pam_umask support for usergroups (man pam_umask) should be mentioned.

>> 3) Add libpam-umask to the base system. And enable the default umask of 002 as
>> described in the README.

pam_umask.so is now part of regular libpam-modules and looks for umask settings in starndard places. No need to supply an override umask in common-session.

>>
>>
>> ---
>>
>> The articulated reason for closing #248140 has been that if an umask of 002
>> would be active instead of the 022 this could lend to unexpected behaviour.
>> The example given was that when copying with scp to systems without UPGs
>> might unexpectedly expose files to write access.
>>
>> However scp should nomaly respect the umask on the target system.
>>
>> Only when explicitly using "scp -p" (preserving permissions) that might not be
>> the case. But when copying files between systems with explicity using
>> switches like these, it seems the user has to be aware of possible
>> implications and inconsistencies in user and group IDs anyway. With "scp -p"
>> as a normal user the copy might belong to the destination user and its
>> primary group, done as root numerical UIDs taken from other systems may
>> always belong to different users.
>>
>> The possibly of users (accidentially) having scp aliased to "scp -p" may seem
>> a little far fetched to warrant shiping debian with a non-working user
>> private group setup by default.
>>
>
>All this seems to be a good summary of things we actually talked
>about, Tollef, Nicolas François and I at Debconf.
>
>The shadow team is still focused on the transition to upstream
>versions, so that subject didn't move a lot since then, but we're
>probably ready to have it advance. Thanks again for taking care of it.
>
>>
>> [1]
>> From #248150
>> login.defs(5) wrongly says that login(1) no
>> longer uses login.defs. TTY mode setting is still controlled by login.defs,
>> for one thing.
>>
>>
>
>These will probably be dealt with after we sync with shadow 4.0.13
>(due very soon).