Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I recently built a very simple test environment with oepnSuSE.

As I tried to configure a shared directory, wihtout using ACLs, but with SetGID on that directory instead for some reason, I noticed that the default umask for every user is set to 022 (i.e. 755 on directories & 644 on files).

This is done in /etc/login.defs.

I am used to a umask 002 (i.e. 775 directories / 664 files) for normal users and 022 for the root-user instead.

Shall I change the umask value for useradd in the above mentioned file, if I want to set it as default for all future useradds and how can I change the umask for all existing users on my system (except the root account, of course)?

share|improve this question

4 Answers 4

up vote 3 down vote accepted

Answering the question in your subject: OpenSuSE uses the traditional Unix umask setting, instead of the Debian-inspired one adopted by some other Linux distributions.

Editing /etc/login.defs should be sufficient to change it; this will not affect users currently logged in, nor is there any way for you to force such a change to programs that are currently running. It will also not affect users who have overridden it in their ~/.profile (or .bash_profile, .login, etc. as per their shell).

useradd is not involved with this; it is a per-process setting and the default is set during login (hence login.defs and not /etc/default/useradd).

share|improve this answer
    
but what is the /etc/defualt/useradd-file used for at all in openSuSE-systems if the /etc/login.defs-file is used anyway? –  Master of Celebration Apr 24 '12 at 8:58
    
It is used for per-account settings. umask is not a per-account setting. –  geekosaur Apr 24 '12 at 9:08
    
but umask is still configured in /etc/default/useradd by openSuSE default configuration! I have no idea why it is, because I didn't do that.. –  Master of Celebration Apr 24 '12 at 9:11
2  
I don't know why either. Some settings of that variety exist but don't actually get used, with notes in manpages saying "we'd like this to work someday but it currently doesn't do anything"; in this particular case it makes no sense because on Linux if it were to work at all it would be part of the PAM configuration. –  geekosaur Apr 24 '12 at 9:22
    
By the way, do you know anything about this "different umask for root user"-thing I mentioned in my question? Is setting a different umask in the /root/.login-file the only way to do that? Or is there a special setting inside the /etc/login.defs-file for root-accounts? –  Master of Celebration Apr 24 '12 at 9:40

The umask 022 (or 0022) is the commonly used umask for UNIX systems which use the traditional style of user account management. In the traditional style of account management, when a user is created, the user is given a default group which would be something like a team or department, or maybe as simple as "users". setgid directories (we could call them "team directories") do not work as expected, because the files are not writable for other team members unless the user makes them writable explicitly. This is not very practicable, especially when the files are opaque to the user, as it would be the case with, for example, a git repository. This is not considered a problem because ACLs provide a perfect solution for that.

The umask 002 (or 0002) is the commonly used umask for UNIX systems which use UPG - User Private Groups. When adding a user in an UPG system, the system creates a group with the same name and group id as the user name and user id. UPG is a Debian-inspired approach of user account management. As you've just experienced, UPG has some advantages when it comes to setgid directories - as long as users do not override their umask. ACLs are safe from that override.

The best solution is to refactor your user and group accounts and enable UPG, then you're "safe".

Warning! When you take a shortcut and simply change the umask in /etc/login.defs to 002 (or 0002) instead of 022 (or 0022), be aware that all files created by all users will per default now be writable by all other users in the same group. This is a security risk, so this is almost certainly not what you want.

One of the reasons for the introduction of the UPG system was that it allows administrators to configure a umask of 002 (or 0002) instead of 022 (or 0022) to easily facilitate the setgid bit for collaborative work on projects without the described security risk.

As far as I know, OpenSUSE does not offer a way to enable UPG during installation or YaST and the only way to use UPG is to purely use the command line for creating user accounts, after making the necessary change to /etc/login.defs: Change it to have USERGROUPS_ENAB yes. There's a pitfall here. UPG only works properly if the user id and the group id are identical. If you do that change to a running system, you will first have to change the ids of the existing groups, which involves re-assigning the groups to all files with these groups, and in the context of LDAP, NFS and NIS this can be a bit hairy.

Here's some further reading on this topic, which I found helpful when I was new to the topic of setgid vs. umask and UPGs:

share|improve this answer

Most unix systems have a 002 umask, i.e. only the user can write files by default.

Having a 022 umask can be useful on systems where each user is in their own primary groups. However, this umask is fraught with dangers. It leads to a lot of support problems with .ssh directories that are group-writable and hence ignored by the SSH daemon. It leads to private files being leaked because they ended up belonging to a shared group. A lot of files end up belonging to the wrong group, so having them group-writable by default isn't such a good idea.

Umask and setgid directories were a bit of a hack in the days when this was the only way to facilitate sharing files between users. Nowadays, ACLs can do a far better job:

  • Permission bits are associated to a particular group (instead of having separate settings for a set of group permissions and a choice of one group that these permissions apply to).
  • The permissions of files don't need to depend on a user setting which users may override, they only depend on the permissions on the directory.
  • Files can have permissions set for more than one group.
  • Files can be shared between users who do not form a group.

Umask is obsolete, use ACLs.

share|improve this answer
    
thank's for reminding me on that fact :-) –  Master of Celebration Apr 25 '12 at 8:48

One difference between e.g. RHEL and (open)SuSE is that RHEL follows the User Private Group scheme in which the primary group of each user is a private group with the same name as the username.

(open)SuSE sets the private group of all users to "users" if I'm not mistaken.

Naturally a umask that allows members of a user's group to read all files is not secure if other users are a member of that group. This is why the default umask is different between (open)SuSE and RHEL and others.

So be sure to check the security implications before changing only the system wide umask!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.