Setting umask for all users

12,061

Solution 1

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.

Solution 2

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:
12,061

Related videos on Youtube

Yarin
Author by

Yarin

Updated on September 18, 2022

Comments

  • Yarin
    Yarin over 1 year

    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?

  • Yarin
    Yarin over 11 years
    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...
  • Zachw6
    Zachw6 over 11 years
    @Yarin I suppose RotatingFileHandler is spawned from root's crontab. You can set umask there.
  • Yarin
    Yarin over 11 years
    Thanks @Soham- how do you know the load order of all these scripts?
  • user9517
    user9517 over 11 years