[Pkg-shadow-devel] Re: summary preparation for technical comittee: setting the umask

[Christian Perrier]

(adding the shadow maintainers list to the CC, and therefore keeping a
whole citation, sorry fot this)

Quoting C. Gatzemeier (c.gatzemeier at tu-bs.de):
> 
> An attempt for a summary to resolve the situation follows.
> 
> Regards,
> Christian
> 
> ---
> 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.
> 
> 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.
> 
> 3) Add libpam-umask to the base system. And enable the default umask of 002 as 
> described in the README.
> 
> 
> ---
> 
> 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).




--