Re: UPG and the default umask
On Sun, 16 May 2010 18:18:14 -0400, Felipe Sateler <fsateler@gmail.com>
wrote:
> Is there a reason to support non-UPG systems?
Not to force users to use anything that they don't want?
btw: While I stopped at some point commenting that issue, when I realised
that general security concerns were simply ignored,... I've seen that there
were plans to automatically detect whether a user could have "secure" UPG,
right?
May I suggest the following:
Either:
1) Debian should make this decision fully configurable (whether to use UPG
and which umask _system wide_ (!) or not). Of course it is already
configurable, but I mean something like configuration during installer
phase, or via debconf at some package where this fits to.
At that/those places, when choosing UPG, only the supposedly "secure"
default umasks could be presented and the user could be taught about the
pros and cons of UPGs.
Or:
2) It should be easy to prevent the now ongoing changes (switching default
umask and so on), and for new installations, easy to go back to the old
way.
3) If you make such automatic checks whether a user can have UPGs
"securely", I guess you should take care that these checks are
"dynamically", as a user may change his groups.
btw2: Has there been a final decision whether this UPG-stuff is also
enabled for system users? Especially things like the users from postgresql,
or other daemons?
btw3: As this change seems to be decided, wouldn't it make sense to change
the UMASK value in login.defs and the currently documentation that tells
some secure values:
# 022 is the "historical" value in Debian for UMASK when it was used
# 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.
#UMASK 022
to the "new" ones with the insecure ones:
# 022 is the "historical" value in Debian for UMASK when it was used
# 002 is the new default for use with user private groups.
# There is no One True Answer here : each sysadmin must make up his/her
# mind.
#UMASK 002
Cheers,
Chris.
Reply to: