If you are new to Linux, or Unix like systems in general, you may find yourself confused by the permissions and access control system on your Linux-based system. This guide provides an introduction to the fundamental concepts behind the permission system, an overview of the commands you can use to manage permissions, and several examples of practical applications of the permission system in production situations.
Linux, which follows the POSIX standard like other Unix-like operating systems (e.g. Solaris, AIX, HP-UX, Mac OS X, Free/Open/NetBSD) is designed to be a fully multi-user operating system and uses a system of users and groups to control who has access to files and programs. As this allows system administrators to exercise very fine grained control over the system and over running programs, we recommend you become familiar with the basic concepts and processes of this system.
These instructions work with the Linode platform. If you don't have a Linode yet, sign up for a Linux VPS and get started today.
On Linux systems, as on all Unix like operating systems, all files, executables, and directories "belong" to (are owned by) a user and a group. Users all have a default group, but typically also belong to multiple additional groups.
Permissions are built on top of this system. While files and directories all have an owner and a group, permissions can be set granularly so that files can be read, written, or executed by their owners, groups, or the "world" (i.e. all users on the system.) The permission system allows for any combination of read/write/execute permission for owner/group/world users.
While we often think of "users" as correlating directly to the human beings who use the machine, many of the "users" on a Linux system are special users created for specific applications, so that executables--particularly ones which are accessible over the network--have a very limited ability to affect the system. For example, the Apache web server runs as www-data on Debian/Ubuntu systems, to limit web users from gaining unnecessary access to the system.
All Linux system have a superuser or "root" user account, which is the first user created on a system. The root user has special access to administer the system; root has the ability to read, write, and execute any file on the system and has "ultimate" authority over the administration of the system.
For this reason, we recommend limiting the use of the root user account as much as possible. Furthermore, it is generally a best practice to isolate users and applications to their own user accounts to limit the potential security risk that any application or user can pose to the system as a whole.
To create normal users, use the adduser command in the following form:
adduser [username]
With the adduser command you can also be more specific with regards to what the user's home directory and default shell will be. The following command creates the user "squire" in the groups "morris" and "leader":
adduser --home /home/squire \ ## specify a conventional home directory
--shell /bin/bash \ ## specify bash as the default shell
--ingroup morris leader squire ## specify to which groups this user should belong
(Note for clarity: everything following the double hash (e.g. ##) is a comment, and the backslash (e.g. \) continues the command onto a second line. You can omit the comments if you like and enter the command on one line.)
This example specifies that the user's default shell will be bash, and that the location of the user's home directory will be /home/squire. Typically, on Linux systems home directories for users are created by default in the form of /home/[username]/.
By default, the "primary" or default user group is the same as the user's username. Additional useful options include:
If you need to modify a user account after the fact, the usermod command may be helpful. The syntax for this command is "usermod [options] [username]" where [username] is the user's specified login name. Useful options include:
To view the file permissions and ownership of a set of files, use the ls -lha command. You'll get output like this:
drwxr-xr-x 2 squire team-members 4.0K 2009-08-13 10:16 docs -rw-r--r-- 1 squire squire 8.1K 2009-07-09 16:23 roster.py
The first column communicates information about the files' permissions, the second column (a numeral) reports the number of files/directories in the directory if an item itself is a directory ("1" if it is simply a file). This is followed by the owner, the group, the size, the date and time of last access, and finally the file or directory name.
The permissions section requires some additional explanation. The first character is either d indicating that the item is a directory, or - indicating that the item is a normal file. The following nine characters are arranged in three groups of possible rwx sequences. The first three refer to "owner" permissions, the second three to group permissions, and the final three to "world" or other users' permissions.
In the example above, the roster.py file is not a directory (-), the owner has read and write privileges but not executing privileges (rw-), the group can read but not write or execute files (r--), and all other users can read but not write or execute the file (r--).
To alter file permissions we use the chmod command to change the permissions or "mode" of the file. There are a number of different ways this command can be used. Most simply the commands are issued in "chmod [options] [mode] [filename]" format. For example, to add execution permissions to roster.py we would use the following command.
chmod +x roster.py
This would make the output of "ls -lha" for that file look like:
-rwxr-xr-x 1 squire squire 8.1K 2009-07-09 16:23 roster.py
You can use + or - in combination with r, w, and x to add or remove read, write, or execute permissions for a file. If you need to add permissions to group members, "world" users, or change write permission non-unilaterally; then it is easier to specify permissions with the octal notation.
The octal notion is helpful for setting permissions for files. These three digit numbers are capable of describing the following:
0 --- indicates no permissions 1 --x indicates execute permissions 2 -w- indicates write permissions 3 -wx indicates write and execute permissions 4 r-- indicates read permissions 5 r-x indicates read and execute permissions 6 rw- indicates read and write permissions 7 rwx indicates read, write, and execute permissions
Each digit is independent of the other two. Therefore, 777, creates read, write, and execute privileges for all users. 744, which is a typical default permission, allows read, write, and execute permissions for the owner, and read permissions for the group and world users. To chmod the roster.py file so that the owner can read, write, and execute the file, the group can read and execute the file, and the world can execute the file, issue the following command:
chmod 751 roster.py
As a result the "ls -lha" listing looks like:
-rwxr-x--x 1 squire squire 8.1K 2009-07-09 16:23 roster.py
If you need to change the permission for a directory and the files contained within it, use the -R option to enable a recursive chmod.
In addition to the most common read/write/execute file permissions, there are a couple of additional modes that you might find useful, specifically the +t mode (the "sticky bit") and the +s mode (the "setuid bit"). These functions describe the behavior of files and executables in multi-user situations.
When set on a file or directory, the sticky bit, or +t mode, means that only the owner (or root) can delete the file, regardless of which users have write access to this file and/or directory by way of group membership or ownership. This is useful when a file or directory is owned by a group through which a number of users share write access to a given set of files.
To set the sticky bit on a file named /root/sticky.txt, issue the following command:
chmod +t /root/sticky.txt
To remove the sticky bit from a file, use the "chmod -t" command. Note that to change the sticky bit, you need to either be root or the owner of the file, and that the root user will be able to delete files regardless of the status of the sticky bit.
The setuid bit, or +s, when set on files, allows users with permissions to execute a given file the ability to run that file with the permissions of that file's owner. For instance, if the file caper was owned by the root user and the dance group, members of dance group could run the caper program as if they were the root user. Obviously this poses potential security risks in some cases, and executables should be properly vetted before receiving the +s flag. To set the +s bit on a file named /usr/bin/caper, issue the following command:
chmod o+s /usr/bin/caper
In contrast to the +s mode for the ownership of a file, the effect of the +s mode on a directory is somewhat different. Files created in +s'd directories receive the ownership of that directory's user and group, rather than the ownership of the user that created the file and their default group. To set the "setguid" (group id) option on a directory, use the following command:
chmod g+s /var/doc-store/
To set the "setuid" (user id) for a directory named /var/doc-store, issue the following command:
chmod o+s /var/doc-store/
By default, all files are "owned" by the user who creates them, and by that user's default group. To change the ownership of a file, we use the chown command in the "chown user:group /path/to/file" format. In the following example we'll change the ownership of the "roster.html" file to be owned by the "squire" user in the "leadership" group:
chown squire:leadership roster.html
To change the ownership of a directory and all the files contained therein we'll use the recursive option with the -R flag. In the following example we change the ownership of /srv/smb/leadership/ to the "foreman" user in the "leadership" group:
chown -R foreman:leadership /srv/smb/leadership/
In many cases user permissions will be used to provide your system with greater security without any direct interaction from you, as packages for manyte operating systems create specific system user accounts during their installation process.
Generally we consider it a best practice to give distinct users their own logins to your system, as this protects each users' files from all other users. Furthermore, using specific accounts for users allows more accurate system logging, particularly when combined with tools like sudo. We recommend avoiding situations where more than one individual knows the password for a user account for maximum security.
In contrast, groups are useful for allowing multiple independent user accounts to collaborate and share files. If you create groups on a machine for common tasks on a per-task basis (e.g. web editors, contributors, content submitters, support) and add relevant users to the relevant groups, these users can all edit and run the same set of files without sharing these files with the world. Use of the chown command with file permissions of 770 and 740 would help accomplish this goal.
You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.
This guide is licensed under a Creative Commons Attribution-No Derivative Works 3.0 United States License
.
Please feel free to redistribute unmodified copies of it as long as attribution is provided, preferably via a link to this page.
|
|
Submitted by Stan Schwertly on Monday, November 23 2009 at 17:48:12 GMT
Thanks for pointing that out. A revised version of this guide will be up shortly.
|
Got a comment?