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
add comment

3 Answers

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
show 3 more comments

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
add comment

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
add comment

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.