FS#8051 - The "shadow" package: please set 700 permissions instead of 755

Attached to Project: Arch Linux
Opened by Oleg Nitz (olegnitz) - Tuesday, 18 September 2007, 08:31 GMT
Last edited by Tom Killian (tomk) - Friday, 30 November 2007, 11:53 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Tom Killian (tomk)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version 2007.08.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Currently by default "useradd -m" creates home directories with 755 permisions, as UMASK is set to 022 in /etc/login.defs. I propose to change the default value of UMASK to 077, so that home directories will be created with 700 permisions. This change should affect new installations only.
I believe that 700 is better default permissions because private home directory is a classic concept for *nix systems (see http://en.wikipedia.org/wiki/Home_directory ). Also note the example of KUser utility from KDE, which creates home directories with 700 permissions.

Additional info:
* package version(s)
shadow 4.0.18.1-5
This task depends upon

Closed by  Tom Killian (tomk)
Friday, 30 November 2007, 11:53 GMT
Reason for closing:  Implemented
Additional comments about closing:  Implemented in shadow 4.0.18.2-1
Comment by Thomas Bächler (brain0) - Tuesday, 18 September 2007, 10:12 GMT
Setting umask to 077 will affect the whole system, the effect will result in lots of breakage - and it will affect existing installations as well.
Comment by Oleg Nitz (olegnitz) - Tuesday, 18 September 2007, 19:29 GMT
Actually there won't be any breakage at all.
"umask 022" is set in /etc/profile and affects all mkdirs done by user, I don't propose to change it.
"UMASK 077" will be set in /etc/login.defs and will affect only home dirs for newly created users.
Comment by Aaron Griffin (phrakture) - Tuesday, 18 September 2007, 19:30 GMT
Reopened. I don't know about the above, but it has some potential merit - Thomas, Tobias, what do you guys think?
Comment by Dan McGee (toofishes) - Tuesday, 18 September 2007, 23:49 GMT
This breaks a lot of X desktops- the gdm/xdm/kdm whatever depends on being able to read .xinitrc and such in a users home directory while running as nobody (or another user with very few permissions).

I'd vote -1- this is something you can do on a case by case basis. If a user knows enough about this to change it and worry about it, then change it on your own.
Comment by Aaron Griffin (phrakture) - Tuesday, 18 September 2007, 23:59 GMT
Yeah Dan has a good point - we don't want gdm et al broken by default.
Comment by Oleg Nitz (olegnitz) - Wednesday, 19 September 2007, 08:11 GMT
Dan, I think you are wrong. I have 700 permissions on my home dir and nothing has broken. Why would gdm/xdm/kdm need to read .xinitrc for some particular user before user loggs in? How does gdm/xdm/kdm know who is sitting in front of monitor? ;-)
Comment by Jan de Groot (JGC) - Wednesday, 19 September 2007, 12:17 GMT
X runs as root because it is setuid, so X can read your homedirectory regardless permissions. Also, startx is executed by your own useraccount, it would be stupid to not have permissions on your own homedir ;)
Comment by Aaron Griffin (phrakture) - Wednesday, 19 September 2007, 16:15 GMT
Ok, so that potential issue is not an issue.

Is there anything else outstanding? Oleg's point made in the comment is sound, as long as we make sure that the umask remains in /etc/profile.
Comment by Tom Killian (tomk) - Tuesday, 27 November 2007, 22:54 GMT
Picking this up, as I'm working on a couple of other shadow bugs prior to the next release. Thomas, do you still have a problem with Oleg's request?
Comment by Oleg Nitz (olegnitz) - Wednesday, 28 November 2007, 11:17 GMT
Tom, could you, please, consider reopening  FS#8050  http://bugs.archlinux.org/task/8050 ?
Comment by Aaron Griffin (phrakture) - Wednesday, 28 November 2007, 16:37 GMT
Isn't  FS#8050  the same fix? Why would we reopen it if it's more-or-less a duplicate of this one?
Comment by Oleg Nitz (olegnitz) - Wednesday, 28 November 2007, 17:15 GMT
No, not the same. There are too utilities for adding new user: adduser and useradd (adduser calls useradd), and now they set permissions differently, adduser to 711 and useradd to 755.  FS#8051  is about useradd,  FS#8050  is about adduser, a proposition to remove several lines from the adduser script, so that adduser will not change permissions set by useradd, whatever they are.
I added two different tasks because  FS#8050  IMHO makes sense even if you don't accept  FS#8051 , it is about clearing things up.

Loading...