Managing default Unix file permissions with adduser and umask

You may recall reading in Understand basic Unix file permissions that:

The fundamental key to basic file-level security on a Unix system is to keep file permissions as restrictive as possible without stopping the system from doing what it needs to do, and without preventing yourself from accessing the files the way you need to access them.

As that article explains, in the general case, system admins for Unix and Linux systems should ensure that the owner of a file gets full permissions for it while other users get no access at all by default. Making sure that happens smoothly without adding a lot of administrative overhead to your day requires automating permissions defaults for new files.

Configuring default home directory permissions

First of all, the permissions for a new user’s home directory can be set when the user is created using the adduser command. How this is accomplished varies, and you should check the manpage for details. On FreeBSD, for example, you can set the initial permissions for a new user’s home directory by executing the command with the -M option. Thus, if you want to create a user account with its home directory permissions set to 750, you would execute this command:

adduser -M 750

On Ubuntu Linux, to get the same result, you must edit the DIR_MODE line in the /etc/adduser.conf file so that it reads:

DIR_MODE=0750

The /etc/adduser.conf file can be used to configure default home directory permissions for user accounts across the board on FreeBSD systems just as it can on Ubuntu Linux systems, but the -M option for the adduser command allows the default set in /etc/adduser.conf to be overridden at the moment adduser is executed.

However you set the default home directory permissions, this ensures that the user’s home directory itself is entirely inaccessible — even for browsing and reading — to any account that does not have root-level privileges, is not the account for which the directory was created, and is not in that account’s default group. It also prohibits deleting the directory even for other accounts in the user account’s default group. Once that directory is created, though, one still needs to automate file permissions defaults for additional files created by that account.

Configuring default file permission masks

File creation masks can help to automate file-level security policy by enforcing a strict default set of file permissions when new files are created. The common technical term used to refer to file creation masks in the Unix world is umask, short for user mask. In POSIX-compliant OS environments, any process has a user mask that limits permission modes for files it creates. The umask itself specifies permissions that are disallowed. Unix-like systems provide a umask command to set the umask for a shell process.

This can be leveraged to affect anything that runs within the context of a user’s login shell. You can do this for all user accounts on a system by specifying a umask default in a system-wide default shell configuration file. For instance, on most Linux distributions, where bash is the default shell, this would be the /etc/profile or /etc/bashrc file. For systems running BSD Unix OSes, where default shells are part of the C shell family like csh and tcsh, the global shell configuration file should be /etc/login.conf.

On FreeBSD, the relevant line in the file probably says something like this by default:

:umask=022:

Because this is a mask that prohibits a particular set of permissions, rather than explicitly setting specific permissions, you should think of those as subtractions from the otherwise default permissions a file may have. For instance, when a process with that umask tries to create a file with permissions 775, it will end up with permissions set to 755 because the permission with a value of 2 (the “write” permission) has been disallowed for the group entity as a default file permission. Because non-directory files are not normally created as executable files, however, the 1 permission (execute) is usually skipped, leaving a umask setting of 022 with the practical effect of causing non-directory files being implicitly set to 644 when created, while directory files will be created with 755 permissions.

A stricter umask for security purposes would be one that prohibits any greater permissions than 750, which would be configured in /etc/login.conf by changing that line so that it reads:

:umask=027:

On Ubuntu Linux, meanwhile, the relevant line in /etc/profile looks like this by default:

umask 022

To change it to automate file creation permissions so they will not be any greater than 750, change that line so it says:

umask 027

Neither case stops the user from explicitly setting a file’s permissions to different values. For instance, if a user creates a file and subsequently decides that it should have permissions 777, its permissions can be changed to suit that purpose with the chmod command:

chmod 777 filename

The shell’s default umask configuration will not prohibit the user from making such a change explicitly. It only sets a default for permissions set implicitly when the file is created.

Default permissions policy

The best default permissions policy for your circumstances will depend on your particular needs. As stated in Understand basic Unix file permissions, there is a simple and effective rule of thumb for maximizing file-level permissions security:

The fundamental key to basic file-level security on a Unix system is to keep file permissions as restrictive as possible without stopping the system from doing what it needs to do, and without preventing yourself from accessing the files the way you need to access them.

This is just a special case of the principle of least privilege — a principle of security worth knowing, and worth repeating.