filesystem permissions

permission systems

there are two common permission systems, with the second available as an extension of the first

three-value permissions

permission information is an association of three values to a file

value-uid, value-gid, value-other -> file

a file can have one user (uid) and one group (gid) related permission.

in regard to the quantity of users the permissions can correspond to

one-user, some-users, all-users

the individual values are themselves composed of three other values

(read write execute)


value-uid:one-user:(read:yes write:yes execute:no)
value-group:some-users:(read:yes write:yes execute:no)
value-other:all-users:(read:yes write:no execute:no)

when a file is created, the permissions are set by the creating program and modified by the kernel for individual processes using "umasks".

access control lists

(path (uid/gid/other/default value) ...)

instead of being limited to permissions only for three types to a file, it is possible to assign permission values for an arbitrary number of entities, which can be users, groups as well as default permissions. the maximum permissions are always limited by the still active three-value permissions, which means access control lists layer on top of the three-value permission system. this system is activated at filesystem mount with a mount option



the retrieval of the effective permissions to a file for a process from the user perspective can be seen as a function with the following signature

path current-process-uid current-process-gid -> file-permissions-for-process


directories are files that contain entries which associate file-names to file inodes. to read from a directory means to read only the file names of entries. access needs translation from file names to file inodes. access is controlled via the execute permission. because of this, the "execute" permission could be called "access" permission for directories



r w x
read write execute

usually written like this with "-" for omitted places

rwx r-x r-x


100 100 001
4 2 1
read write execute

usually summed for each position. single digit octal numbers can always have an exact 3 bit representation


(+ 4 2 1) (+ 4 1) (+ 4 1)
111 101 101

needs fewer characters than the letter notation

example patterns

files not shared with other users

permissions for non-directories

owner: rw-
group: ---
other: ---

octal 600

permissions for directories

owner: rwx
group: ---
other: ---


files shared with a group

permissions for non-directories

owner: rw-
group: r--
other: ---


permissions for directories

owner: rwx
group: r-x
other: ---


ensuring permissions

one may create and execute a script that sets up the file-permissions, maybe called regularly. without such a script, unwanted changes to permissions could stay undiscovered and be a security risk and make other problems or would have to be manually resetted when discovered



can display permissions of files in directories (the current directory if unspecified). example: ls -l


"change mode" - changes permissions of files. example: chmod 600 /tmp


"change owner" - changes owner and group of files.

  • example: chown username:groupname /tmp
  • example: chown -h username: /tmp sets to username:username. useful if group equals user name

for security, only the root user can change the owner. on some systems like gnu/linux, symlinks have an owner and group. chown -h username:groupname mysymlink


displays access control list permissions, acl. example: getfacl *


sets acl permissions. example: setfacl -m u:username:rw path


filters and displays files in directory trees. can be used to set permissions selectively. example: find -type f |xargs -n 1 -d \n chmod 600


sets the current process' umask, sub-processes usually inherit it. it is specified as a subtraction from full permission (777). example: umask 133

troubleshooting permission issues

  • webservers

    • check the permissions of the target path and all parent directories
    • check if the path includes symlinks and if symlinks must be explicitly allowed
  • services

    • check if directory access limitations are configured in the systemd service file
  • sockets

    • socket files also have filesystem permissions. check if whoever is trying to access the socket has the necessary permissions
  • docker containers

    • container installations use a different user table
    • one option is to create a user with the same user id and name in the container
  • git dubious ownership

    • git does not track file permission changes in the repository except for the execute bit