Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to set the default umask to 002 for all users including root on my CentOS box.

According to this and other answers, this can be achieved by editing /etc/profile. However the comments at the top of that file say:

It's NOT a good idea to change this file unless you know what you are doing. It's much better to create a custom.sh shell script in /etc/profile.d/ to make custom changes to your environment, as this will prevent the need for merging in future updates.

So I went ahead and created the following file:
/etc/profile.d/myapp.sh
with the single line:

umask 002

Now, when I create a file logged in as root, the file is born with 664 permissions, the way I had hoped. But files created by my Apache mod_wsgi application, or files created with sudo, still default to 644 permissions...

$ touch newfile (as root):
Result = 664 (Works)

$ sudo touch newfile:
Result = 644 (Doesn't work)

Files created by Apache mod_wsgi app:
Result = 644 (Doesn't work)

Files created by Python's RotatingFileHandler:
Result = 644 (Doesn't work)

Why is this happening, and how can I ensure 664 file permissions system wide, no matter what creates the file?

share|improve this question
    
If by WSGI you mean mod_wsgi, then use mod_wsgi daemon mode and WSGIDaemonProcess has a umask setting. –  Graham Dumpleton Dec 16 '12 at 22:23
    
Sweet, thanks Graham –  Yarin Dec 18 '12 at 20:01
add comment

2 Answers

up vote 5 down vote accepted

profile is a startup file for the shell. Setting umask 002 in profile.d sets it for all users who start their processes from a login shell.

Your two examples are of a different nature. For Apache you might set the umask in the init.d script that starts the http server.

For processes started with sudo you could use the umask option in the sudoers file.

share|improve this answer
    
Dmitri- thanks, this makes sense. How would you deal with files created by a Python process running as root? We're having the same issue with files created by Python's RotatingFileHandler... –  Yarin Dec 16 '12 at 18:38
1  
@Yarin I suppose RotatingFileHandler is spawned from root's crontab. You can set umask there. –  Dmitri Chubarov Dec 16 '12 at 18:41
    
Great thanks for the suggestions –  Yarin Dec 16 '12 at 18:42
add comment

The best way to get the umask thing done is to edit the /etc/bashrc file for root and ~/.bashrc file for other users. Anything you put in ~/.bashrc for a particular user is gonna override what you put in /etc/profile.

So, find out under which user your apache is running and put umask in the ~./bashrc file.

This goes for users. It includes interactive user logins and can be get to work by sourcing the files. Doesn't require logging out and in.

But if you are going to set umask for daemons, then you need to get into the init script and put the umask there after it sources the /etc/rc.d/init.d/functions file. If you set umask before that, it might not work. But I have seen some daemons which do not work even when you set umask in their init script, a quick example would be cobblerd in RHEL. For that, you need to put umask in /etc/rc.d/init.d/functions file itself.

But mostly by putting umask value in ~/.bashrc file works.

This is how I have got it to work so far, but if other opinions come across, I would be glad to know.

share|improve this answer
    
Thanks @Soham- how do you know the load order of all these scripts? –  Yarin Dec 16 '12 at 18:43
2  
    
@Soham - awesome, thanks –  Yarin Dec 16 '12 at 18:54
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.