File permissions in *NIX systems

Understanding file permissions in Unix / Linux based systems, and how to make files immutable.

155 views

By. Jacob

Edited: 2023-10-17 08:33

4+2 = 6 read and write

4+1 = 5 read and execute

4+2+1 = 7 read, write, and execute

2+1 = 3 write and execute

400 owner has read access, everyone else has nothing. Used for ssh key files.

755 full access to owner, everyone else only has read and execute.

775 full access to owner and group, everyone else only has read and execute.

The order is: owner (7)|group (7)|others (5). E.g.: chmod 775 -R /var/www, which is commonly used for web servers.

You do not have to remember permissions for the chmod command; *NIX permissions has a system to them that makes it easier to figure out how to arrive at various configurations, so simply by remembering the following:

read (r) = 4
write (w) = 2
execute (x) = 1
no permission = 0

You should be able to deduce the correct chmod number for the specific configurations. For example, 4+2 = 6 (read and write), and 4+2+1 = 7 (read, write and execute).

Setting permissions

Permissions is mainly controlled with chmod and chown; the following sections discusses some of the common configurations for various files and circumstances.

Apache and Nginx

Permissions for each virtual host root directory, including most subdirectories and files, should ideally be set to 0755; this is because the web server user (Often www-data), should not be allowed to modify the application files such as .php. The downside to a restrictive setting like this is that a "web updater" service might not work, and you would need to manually update through a terminal instead.

But, web applications may contain exploits that allow an attacker to modify the .php files, so by carefully setting the permissions to 0755, we can contain the damage from such potential exploits. Alternatively, 0775 can be used if you wish to allow "web updaters", but note that some CMS systems are more notorious for being hacked than others. E.g. Wordpress plugins are sometimes particularly insecure and badly designed.

The ownership should typically be set as www-data as the user, and the same for the group; you can adopt this configuration recursively by using the -R parameter:

chown www-data:www-data -R /var/www
chmod 775 -R /var/www

Key files for connecting with ssh / SFTP

Permissions for ssh key files would be 0400. E.g:

chmod 400 $USER/keyfiles/my-key-file.pem

Strange permission combinations

The careful observer will have noticed examples like 2+1 = 3, making it possible to do things like chmod 333 some-file-path; this allows you to make a file writable and executable but not readable. This is useful on directories, for example, and will allow users to write a file to a directory, but not read files from it.

The fact that a file is executable does not automatically grant read access to the file. Binaries will be executable without being readable, but bash scripts will need both to be readable and executable. This is because /bin/bash needs to read the file in order to execute it – note there may be loopholes to such limitations, but it is beyond the point of this article.

File permissions are not inherited, so the permissions on a directory is not passed on to files inside the directory. You can however change permissions recursively (-R). E.g:

chown www-data:www-data -R /var/www
chmod 775 -R /var/www

Making files unmodifiable, even to root

Files can be made immutable, which means that not even the root user will be able to modify or delete the file until the immutable attribute is removed. This is done with the chattr command. E.g to add immutable +i:

chattr +i path/to/file

And to remove the immutable attribute -i:

chattr -i path/to/file