Change the default umask to 0002

Registered by Allison Karlitskaya

With every user having their own group, the "historical" umask of 0022 is excessively restrictive. The main disadvantage is that it prevents setting up shared directories for common access (source control repositories, for example). Note that Fedora has a default umask of 0002 now. This discussion involves how (and if) to migrate and the possible negative security implications of such a migration.

Blueprint information

Status:
Complete
Approver:
Kees Cook
Priority:
Low
Drafter:
Allison Karlitskaya
Direction:
Approved
Assignee:
Martin Pitt
Definition:
Approved
Series goal:
Accepted for oneiric
Implementation:
Implemented
Milestone target:
milestone icon ubuntu-11.10-beta-1
Started by
Allison Karlitskaya
Completed by
Martin Pitt

Whiteboard

Work items:
review http://bugs.debian.org/583958 for extended usergroups features: DONE
remove 'umask 022' from /etc/profile: DONE
read USERGROUPS_ENAB from login_defs in pam_umask, replacing the old "usergroups" option: DONE
document "usergroups" pam_umask option as deprecated: DONE
update UMASK documentation in login.defs for new behaviour (http://bugs.debian.org/583971): DONE

Agreed upon by everyone: will change umask to 002 for non-root users who are members of their own personal group.

pitti, 2011-05-04: Fishing out this lost spec for oneiric. Kees, can you please review this? Does that sound ok to you?
kees, 2011-05-27: Yeah, this looks fine.

vorlon, 2011-05-27: has anyone worked out where "using" pam_umask.so should actually happen? Is the plan to enable this in /etc/pam.d/common-session*, or in per-application configs? Is changing the umask for all session-providing PAM services an ok thing to do?
btw, I would particularly welcome on Debian bug #583958 someone implementing support for grabbing the 'usergroups' default out of /etc/login.defs.

pitti, 2011-05-31: My understanding and feeling is that this should be in common-session. Having different umasks in different kinds of logins sounds confusing to me. Kees?

kees, 2011-05-31: Right, when we discussed this at UDS, common-session was the target. I haven't tested this myself, though.

pitti, 2011-06-22: work item for adding pam_umask to common-session* moved from whiteboard to linked bug

pitti, 2011-06-22: PAM side implemented in linked branch, merge proposal sent to Steve for review; will implement login.defs documentation once the PAM patch is accepted

ceg, 2011-06-22: Would the issues that depend on working 002 with UPGs be considered to belong to this blueprint?:
http://lists.debian.org/debian-devel/2010/06/msg00020.html
https://wiki.ubuntu.com/MultiUserManagement Bug #549117 Bug #252351

jdstrand, 2011-10-10: interesting side-effect when a developer is using a umask of 0022 and expects the packaging to dtrt. On upload, the buildd will extract during the build, using the default umask in Ubuntu (0002) and there might be a disparity between what the developer expects and what the end result is. cjwatson reminds me that this should only be a problem for packages that do not use dh_fixperms (eg base-files bug #871977). Packages which do not use dh_fixperms probably need to have a bug filed against them. Packages using dh_fixperms -Xfoo may need to have a bug filed against them (eg, bug #872000).

(?)

Work Items