- Home
- Learn Linux
- Learn Electronics
- Raspberry Pi
- Programming
- Projects
- LPI certification
- News & Reviews
Linux file access permissions are used to control who is able to read, write and execute a certain file. This is an important consideration due to the multi-user nature of Linux systems and as a security mechanism to protect the critical system files both from the individual user and from any malicious software or viruses. Access permissions are implemented at a file level with the appropriate permission set based on the file owner, the group owner of the file and world wide access. In Linux, directories are also files and therefore the file permissions apply on a directory level as well, although some permissions are applied differently depending upon whether the file is a regular file or directory.
As devices are also represented as files then the same permissions commands can be applied to access to certain resources or external devices.
The group mechanism provides each user with a default group (also known as a primary group), but then allows the users to be added to additional groups. This allows users to be given the appropriate level of access by creating a group for each department or job function, restricting access to those groups.
The default group for each user is determined by the set-up of the system. This is normally configured to create a group with the same name as the username that only that user is a member of. This is the most secure default as it means that there are no other users with default access. An alternative is to have a default group that all users have when created.
The access permission design allows a good amount of flexibility in what permissions can be applied. For example it is possible to restrict access to the owner; make files publicly viewable but only editable by the owner and also to apply different permissions based on a group (e.g. members of the same department). There also also features that can also be used to give permissions as though another user (suid). If something beyond the standard file permissions is required then access control lists can be used instead (ACLs). The use of ACLs is less commonly used and they are not discussed in detail here.
For most of this document I will refer to users and groups by their names. This is the most common and user-friendly way of understanding file permissions. It should however be noted that behind the scenes this is stored as numerical userids (uid) or groupids (gid). The translation from uid / gid is handled by the operating system and the reference stored on the disk is the numerical id. This is not normally important on a single system, but it should be considered when transferring files using an archiving tool (eg. tar) or when moving a disk from one system to another. If the usernames / groupnames have a different numerical uid / gid then access may be given where it is not expected, or rejected where it is required.
The translation between username and userid (uid) is stored in the /etc/passwd file, and the translation from groupname to groupid (gid) is in the /etc/group file. The /etc/passwd file also includes the users primary (default) group and the /etc/group file includes all users that are members of each group (although does not list the user where that is their primary group).
There is a special user on each system with unlimited access to the system. This user has username and groupname of root and the numerical uid and gid of 0. This user is required to allow administrative actions that are not granted under the other users and for certain daemons that have full access to the system. This user is defined by the uid - so multiple superusers could be created by creating multiple entries with this uid. This is not recommended as it provides a potential security issue (see sudo below for the recommended method of providing root access to normal users).
Depending upon the setup and whether physically on the computer or access it remotely it may or may not be possible to login directly as root. It is strongly recommended not to login as root unless it is absolutely necessary due to the risk of accidental deleting important information.
When logging on to a Linux computer you will normally have user level privileges. To elevate to root user access the commands su or sudo are used. These can actually be used to switch to any user, but it is most commonly used when root privileges are required. The commands su and sudo are run on the command line, but there is a graphical version called gksudo. When access is required in a graphical application then it will normally be set-up to prompt for the appropriate authentication automatically. Alternatively it is sometimes possible to right click on an application icon and choose "Run as adminstrator" or "Run as root".
su- The su command is normally used where the user knows the password of the user that they wish to run as. By default this will switch to the root user and the command is often (incorrectly) referred to as the superuser command. If a username is entered on the command-line then it will change to that user instead. If you are already running as root (perhaps through su already) then it will not prompt for a password.
The '-' (hyphen) can be used to also take the user settings as (e.g. search path) as well as privileges.
The command syntax is:
su [-] [username]
The following screenshot shows a user switching to the superuser. Note that the root password is entered, not the users password.
stewart@linuxserver1:~$ su -
Password:
root@linuxserver1:~#sudo - The sudo command can be used as an alternative to the su command, and on some systems in used exclusively (e.g. Ubuntu). The sudo command can be much more flexible than su, depending upon how it is configured. For example sudo can be configured to restrict administrator privileges to certain commands and could even be configured so that the user is not required to enter a password when using sudo (careful thought needs to be made as to the security of the application and whether an unattended session could allow someone to gain access permissions). Where sudo requests the user to enter a password this is normally their own password rather than the root password (Ubuntu and some other distributions take this further by not having a root password meaning that root access can only be obtained through sudo).
Once the user has authenticated themselves using sudo it will normally have a period of time where sudo can be run without having to re-enter the password. This is particularly useful when used with another feature of sudo that allows commands to be run directly rather than changing the permission of the shell session. For example the following example is often used on Ubuntu to install a new application:
sudo apt-get install applicationname
If you wish to run a shell session instead then either the shell should be run on the command-line e.g.
sudo bash
or the -s switch used.
sudo -s
In the example below the user is required to authenticate the first time then run sudo, but can then run subsequent commands without having to re-authenticate. The password given is the users own password and not the root password.
stewart@linuxserver1:~$ sudo ls /etc/security
[sudo] password for stewart:
access.conf limits.conf namespace.init pam_env.conf time.conf
group.conf namespace.conf opasswd sepermit.conf
stewart@linuxserver1:~$ sudo ls /etc/security
access.conf limits.conf namespace.init pam_env.conf time.conf
group.conf namespace.conf opasswd sepermit.conf
stewart@linuxserver1:~$ Note I have made the text bold and added a blank space to show the same command being run twice. The password was requested when the command was first run, but not on subsequent runs using the sudo command as it will remember recent authentications.
To run a command as a user other than root the -u username switch is used before the command.
The configuration of sudo is contained within the /etc/sudoers file.
The following show some of the sudoers configuration options. Note that the admin or wheel groups are commonly used to restrict who can run sudo but this is a popular convention rather than a rule. It is possible to use any groupname, or sudo can be configured by listing the authorised users in the sudoers file.
A further advantage of sudo is that user access is logged which may be required as a security feature on a server with multiple adminstrators. For security and configuration options sudo is usually preferred over su.
The following extract allows root or members of the admin group to su to any other user.
# User privilege specification
root ALL=(ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALLHaving discussed the different types of users and groups these are then applied to files based on the file permissions. This does not just apply to data files, but can be applied to directories to determine who can change to the particular directory and to commands to restrict who can run that command.
To understand the way that permissions work it is often useful to understand how the file permissions are stored on the disk. This gets a little technical so if you don't feel ready for this feel free to skip to the next section on file permissions.
Each file on disk has two parts. The Inode which describes the file and the data blocks that actually hold the data. The file permissions are contained within the Inode for the file.
The following information is kept within the Inode:
Size of file
Permissions
Date & time of creation
Date & time of last modification
Link count
It is the Inode that is referenced by the operating system when determining if a user has the relevant permissions.
Directories exist as links to the Inodes of all the files (or other sub-directories) contained within that directory. This is shown below;
Directory structure on the disk
The file permissions can be seen by using the ls command with the -l (long listing option) as shown below
ls -l
total 0
-rwxr-xr-x 1 stewart stewart 0 2009-01-30 17:00 executable
-r--r--r-- 1 stewart stewart 0 2009-01-30 16:58 read-only-all.txt
-rw-rw-r-- 1 stewart engineers 0 2009-01-30 16:59 read-write-group.txtFrom the ls output the file permissions can be seen at the left.
These are the first 10 characters of the file entry. The first character relates to the file type then the remaining are in 3 groups of 3 characters relating to the different access types.
These permissions are applied to (left to right)
user - the owner of the file
group - a group of people, e.g. a project team or department
others - anyone else that has a login to the computer
These are then split into 3 different permissions, that of being able to:
read - Look at the contents of a file / find out what files are in a directory write - Change or delete the contents of a file / create or remove files in a directory execute - Can execute (run as a program) a file / can change to the directory or copy from the directory.
These are laid out as follows (note these are the first 10 characters of the ls -l display):
Access permission layout
If the entry is filled in then it is in affect. If it is dashed out '-' then it does not apply.
There are also further permissions that can be set, however these are more advanced and are explained later. Also note that root can override most of the permissions.
Assuming that you are either the owner of the file or root it is possible for you to change the permissions of a file to either add or remove permissions. This is done using the chmod (change mode) command.
The chmod command can be used in one of two ways. The Symbolic Format or the octal format. Symbolic is useful for new users as it is easier to use, however if effort is made to understand the octal format then it can be a powerful and quick way of changing file permissions.
The basic format of the command is:
chmod mode filename
It is only the format of the mode parameter that is different when using the different permission formats.
In symbolic format permissions are added or deleted using the following symbols
u = owner of the file (user) g = groups owner (group) o = anyone else on the system (other) + = add permission - = remove permission r = read permission w = write permission x = execute permission
For example to add write access to the group the following command is used:
chmod g+w file1
In Octal format the mode is based upon a octal number representing the different mode permissions, where each of the permission groups (user, group, others) has an octal value representing the read, write and execute bits. This requires a little bit of knowledge on binary or octal number bases. The format is actually octal (but this can be likened to 3 separate binary to decimal conversions for each of the user/group/all permissions). The main benefits of using octal format is that all the permissions are set at the same time and the command is much shorter than if all the permissions were set using the symbolic format.
User Group Others
Symbolic rwx rw- r--
Binary 111 110 100
4+2+1 4+2+0 4+0+0
Octal 7 6 4
The above file would have the octal number 764 and would therefore be changed using the command
chmod 764 file1
An alternative way of working out the octal values is to add the following numbers depending upon the permission required.
Read = 4
Write = 2
Execute = 1
Therefore if you wanted to set read to yes, write to no and execute to yes, this would be 4+1=5
So far we have covered the most common file permissions that users will need to be familiar with. There is a further set of permissions that gives more functionality beyond that of the standard permissions. These are the setuid and setgid options, and the sticky bit. These are shown by ls within the normal file permissions by replacing the execute bit is normally shown by replacing it with S, s, T or t as appropriate.
A lower case s is used where the execute bit is on, and an upper case S where the execute bit is not set.
When used on an executable file this will make the command run as the owner of the file (often root) rather than the person that launched the application. This is required where a regular user needs to run a program that needs to access files that can only be read/written to by root. For example the passwd command which needs to access the protected shadow password file:
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 37084 2009-04-04 06:49 /usr/bin/passwdIt can however be a security risk if it is set on a command that either has a way that users can run other commands (as they will also run as root), or if there is a bug in the application.
The setgid bit is similar to the setuid bit, but is set on the group permissions. This means that a command will run as the group that owns the file rather than the user's default group.
The sticky bit is used to restrict who can delete a file in a directory. When viewing using ls it replaces the world execute permission with a lower case t if the execute bit is set on, and an upper case T if the execute bit is off. When this is set on a directory then only the owner of a file (or root) can delete a file within that directory. This is used in the /tmp directory to allow users to create temporary files, but stop anyone other than that user from deleting the temporary file.
ls -ld /tmp
drwxrwxrwt 20 root root 413696 2009-08-14 15:39 /tmpTo set any of these special permissions using the octal format then an additional digit is used before the rest of the octal number. This is created the same as another octal value using setuid, setgid, sticky in place of rwx.
For example the octal number 4755, would set the setuid bit (4) and the rest of the permissions as per the passwd command shown previously.
The owner and group owner of a file is normally set to the user and default group of the person that created the file.
The owner or group can be changed using the chown (change owner) command.
The format is as follows:
chown user:group filename
The default permission for new files created depends upon the umask value.
Umask works by restricting what permissions are given to a file when it is created by a new program. If the program tries to give full permissions then the umask will restrict what permissions are actually set. If however the program requests permissions that are less than the umask then umask will not add any additional permissions.
The mask works by applying the negative of the umask setting anded with the permissions requested. In effect performing an AND NOT against the umask value.
This is set in the /etc/profile or /etc/bashrc for all users, but can be changed in the users ~/.bashrc
The umask should be set as a inverse mask of the permissions required.
For example the umask of 077 will mean that the group and all users have no permission.
