Based on the reaction to these issues and JENKINS-24514, I'm partially
reverting the original change, and bringing the umask default back to
022.
The configurable option does enable the user to choose a different
umask, so I think I can still claim that JENKINS-24514 is addressed.
Both 0 and 1 are used to indicate some kind of success (the latter when Jenkins doesn't need to be started because it was already running), so we need to return 2.
Ubuntu (at least as of 12.04) has the default umask 022, which made some
users nervous. Quoting its /etc/login.defs below, which explains its
historical origin:
UMASK is the default umask value for pam_umask and is used by
useradd and newusers to set the mode of the new home directories.
022 is the "historical" value in Debian for UMASK
027, or even 077, could be considered better for privacy
There is no One True Answer here : each sysadmin must make up his/her
mind.
It does seem to me that a bit more restrictive default is sensible,
so this change introduces /etc/default/jenkins parameter that sets the
default umask to 027 to prevent "others" from seeing files.
Not that keys and other sensitive files are protected anyway, so it is
not the case that the privacy of Jenkins data files have been vulnerable
prior to this change.
In git commit 7216aab0d the check for present user was removed
and therefore upgrading the Debian package on existing Jenkins
installations fails. Also the newly added code for adding a
configurable Jenkins group is missing a check for a possibly
already present Jenkins group.
Closes: JENKINS-22710
Typical Debian practice is to have one equally-named group per system
user. Make that for the jenkins user by default, but allow it to be
overridden in /etc/default/jenkins, same as for the user name.