Umask Setting In /etc/profile Not Working
Hey all,
We have the following set in /etc/profile :
umask 0002
so that it will affect all users. That should create all files as 664 and all directories as 775 if I’m not mistaken.
Well I logged into the machine after this was set and just created a file as one of the users who complained about permissions settings on files. And this is what I saw:
[user1@qa_host ~]$ ls -l test_qa
-rw-r–r– 1 user1 domain^users 0 Jun 11 10:08 test_qa
I even tried logging out and logging in again just to be sure. I still got the same result.
So my question is why would the file not have the permissions specified by the umask command in /etc/profile ? I really need this to work for the users.
Any helps or clues would be great!
Thanks Tim
6 thoughts on - Umask Setting In /etc/profile Not Working
depending on your shell; are you sure you’re referencing
/etc/profile at all? e.g. are you using bash or bourne?
the prompt looks pretty bash like, but assumptions and all. are you sure there’s not another umask entry either in the user’s homedir .file or in something like /etc/bashrc…
I have a fairly recent install of CentOS 6.5 and get:
[root@critter etc]# grep -i “umask” *
bashrc: # By default, we want umask to get set. This sets it for non-login shell. bashrc: umask 002
bashrc: umask 022
bashrc: umask 077
csh.cshrc: umask 002
csh.cshrc: umask 022
login.defs:UMASK 077
php.ini:; does not overwrite the process’s umask. profile:# By default, we want umask to get set. This sets it for login shell profile: umask 002
profile: umask 022
and the php.ini warning is useful to keep in mind; you can’t add back perms with umask, it can only take away. so if you start off with reference to /etc/profile that does umask 022, which then calls /etc/system-settings.profile that calls umask 077, then get to the users .bashrc file and try to do umask 002, you’ll still be removing all perms for group and other, the last call won’t change anything.
Thanks. We’re using bash here. And I became the user who complained and could not find another umask setting:
[user1@qa_host ~]$ grep -i “umask” *
[user1@qa_host ~]$
possibly; although you can also screw things up pretty well if the user has done something like.. mkdir x; cd x ; ln -sf /etc ./et_cetera_config_files
but /etc/profile isn’t the only thing that bash calls/uses (at least not by default)
what do you get if you do a ‘egrep umask /etc/*’ ?
and in the home dir, what do you get from egrep umask .??* ?
Ok. Crap I hope not. I just did this. Should’ve waited for some advice. The sites are still up so I guess that’s a good sign. Still I hope nothing too bad happened!
This is what I have.. although I think everything I see is already set the way that we want. Unless umask 002 doesn’t correspond to umask 0002.
[root@uszmpwsld011 apps]# grep umask /etc/*
/etc/bashrc: umask 002
/etc/bashrc: umask 002
/etc/csh.cshrc: umask 002
/etc/csh.cshrc: umask 022
/etc/csh.login:# Set umask consistently with bash for loginshells
(csh.login sourced
/etc/csh.login:# after csh.cshrc unlike with bash profile/bashrc scripts and umask
/etc/csh.login: umask 002
/etc/csh.login: umask 022
/etc/ltrace.conf:octal umask(octal);
/etc/ltrace.conf:octal SYS_umask(octal);
/etc/php.ini:; does not overwrite the process’s umask.
/etc/php.ini.2.bak:; does not overwrite the process’s umask.
/etc/profile:umask 0002
/etc/xinetd.conf: umask = 002
And as I mentioned all users are using bash.
Thanks Tim
Am 11.06.2014 um 16:14 schrieb Tim Dunphy:
Tim, briefly, don’t do that. This (mentioned umask in profile)
should be classified as bad practice. What is your primarily goal? What is the users scenario?
Take a look into ACL (rpm package acl):
$ man setfacl
$ man getfacl
There exist a “default” setting to inherit such settings (e.g. write operations for groups).
Login as the ‘user’ and do the following:
grep -i umask $HOME/{.bash*,.profile}
and make sure the user is not resetting the system default.
— Arun Khan