Last updated on: 2019-03-07
Authored by: Rackspace community
This article explores the core concepts of Linux® file permissions. It starts with the basics and moves on to more advanced topics. It also provides some practical examples. To get an introduction to file permissions and to learn how to view file permissions, see Check Linux file permissions with ls.
In a multiuser environment like Linux, it’s important to control which users can modify or delete various files on the system. This control isn’t just a necessary security precaution—it prevents catastrophic accidents. If a user can only affect a minimum number of files, there’s less chance that a mistyped command, or a typo in a script, destroys an essential file or publishes confidential information to a public web site.
Before exploring how to manage file access, you first need to understand the concepts of file ownership and file permissions. Note that ownership and permissions also apply to directories because directories are basically a special kind of file as far as the filesystem is concerned. Even though there are some differences for directories, the basic concepts are the same, so most file permission concepts or commands discussed in this article apply to directories, too.
Every file and directory on a Linux file system has an owner. The owner of a
file gets to assign permissions for the file. If user
mom123 owns the file
lawndarts, you need permission from
mom123 to play with lawndarts. She
might give you access, deny you access to it altogether, or just let you look at
lawndarts without getting to play with it.
The user who owns a file gets to set or change its permissions, determining who (including even the owner) can read the file, execute it, change it, or delete it. It’s a simple privilege, but it has a far-reaching impact.
While every file has a user who owns it and can control its permissions, every file also belongs to a group. A group describes a set of users who share file permissions that might be different from the typical user. A user can belong to more than one group, but a file can be in only one group.
Group ownership is a handy way to let a file owner assign one set of permissions to a file for people he doesn’t know (“You can look, but can’t touch.”) and another set of permissions for people he trusts with the file (“You can look and touch. But no one else can.”).
A typical user can control a file’s permissions but can’t assign ownership to
another user. To change ownership, you need to use the superuser, commonly known
If you aren’t logged in as
root, you should use the
sudo command to use root
privileges to change a file’s owner.
The file system is more flexible about changing a file’s group. You can still use root privileges to change the group, but if the file’s owner belongs to the target group, the file’s owner can also switch a file to the target group.
The main command used to change a file’s owner or group is
chown. The most
common syntax used with
chown is shown in the following example:
chown user:group file1 file2 file3
user in the preceding example is the user you want to own the file, and
group is the group you want the file to belong to. A colon separates the
two elements of the command. Following the user and group pair, you list one or
more files affected by the change.
chown also accepts a period in place of the colon when separating
the user and group names. Use of the period is outdated but still supported, and
you might see it in old scripts or documentation. You should use the colon, if
You can omit either the user or the group but not both. If you want to change only the owner for a file, you can use the following syntax:
chown user file1
If you have a user name that includes a period and you don’t want to change the group, include the colon after the user as shown in the following example:
chown john.smith: file1
If you want to use
chown to just change the group, make sure to include the
colon before the group name, even though you won’t be specifying a user as shown
in the following example:
chown :group file1
If you prefer not to use the colon when you just want to change the group for a
file, you can use
chgrp as shown in the following example:
chgrp group file1
This works just like
chown :group file1, but it’s easier to type and read.
If you want to change the owner a particular directory and its files and
subdirectories, use the
-R option to make a recursive change as shown in the
chown -R user:group directoryname
-R option works with
chgrp as well. With both commands, the change
applies first to the parent directory and then iterates through everything
inside the directory (including subdirectories).
Symbolic links (symlinks) require special handling for
operations. A symlink is an alias for another file, similar to a shortcut in
Microsoft® Windows®. Rather than applying the change to the symlink
itself, the file system applies the change to the target of the symlink. Thus,
if the symlink link points to the file thefile.txt, consider the
chown user:group link
When that command executes, the system changes the owner and group for the target file thefile.txt. The ownership of the symlink, link remains unchanged.
If you want to change the owner or group of a symlink, use the
-h flag for
chgrp, as shown in the following example:
chown -h user:group link
There are two parts to permissions: what someone is allowed to do with a file, and who that someone can be.
There are three categories of user actions for files and directories: read, write, and execute.
The read permission for a file controls who can open or view a file’s contents.
The read permission for a directory controls whether or not you can see a list of the files in the directory, however, read permission is not enough. You also need execute permission for the directory to see the file list.
The write permission for a file controls whether or not you can change the file’s contents.
The write permission for a directory controls whether or not you can add, delete, or rename files in that directory. To exercise your write permissions in a directory, you also need execute permission for the directory.
Note: Only the write permission on the enclosing directory affects whether
or not you can rename or delete a file. Some operations, like
rm, do a check
and prevent you from deleting a file you don’t own. There’s nothing stopping
another program that doesn’t have a similar check built into it from deleting
a file you can’t write to and don’t own.
The execute permission for a file allows you to run that file from the command
line. To run any command (
rm, and so on), you have to have
execute permission for the file representing that command. If you try to
run a command and get a
permission denied error, you don’t have execute
The execute permission for a directory lets you perform an operation in that
directory or to change your working directory (
cd) to that directory.
Even if you have read permission for a directory you can’t actually run the
command in that directory to see the list of files unless you also have the
execute permission. Otherwise, when you try to run
ls, you are blocked before
the system can even check for read permission. To affect anything inside a
directory, you need have execute permission for the directory.
Now that you know what permissions are available, consider the categories used to control who gets affected by those permissions. The categories are user, group, and other.
The user permission category refers to permissions that apply to the owner of the file. It’s the only category that specifically targets only one user because only one user can own the file.
The group category refers to users that are in the same group as the file. If the file is in the group devs, and the file has write permission for its group, that would mean that users in the devs group have write access to the file.
The other category is a catch-all for everyone who doesn’t fall under the user or group categories. You use this category to determine whether other users can read the file, edit it, or run it as a command.
It’s important to note that permission categories are applied in the order user, group, other. The first permission category the system finds for a user is the only one it applies. If you’re the owner of the file, your permissions are whatever is set for the user, so the system won’t bother checking the group or other permissions for the file—it has already found what it’s going to use.
This concept is important because if you set a permission for other, that permission is not applied to the file’s owner or to anyone in that file’s group. Those users get the permissions set in the user or group categories, respectively.
If you don’t set a read permission on a file for the group category but do set it for the user and other categories, users in the file’s group do not have read access, but everyone else does.
Combining ownership, user categories, and permissions provides many options for controlling access to files and directories. The following examples show some possibilities:
If you make a file read-only for the other category but let the user and group categories write to it, then you can establish a group of editors for a file while still allowing other users to read it. Just add the privileged users to the same group as the file.
If you set read permission for the user category and remove it from the group and other categories, you ensure that only the owner of the file can view its contents.
When you set execute permission for a file, you allow it to be run as a command. If you have a command you only want specific users to be able to run, remove the execute permission on the file for the other category.
Directories get the same treatment. Many system log directories are set to read
and execute by just the user category (often
root) and exclude those
permissions from other categories to ensure that only someone with superuser
access can view the logs, no matter what permissions are set on the files
The root user exists to provide access and control. The root user can change the ownership and permissions of any file or directory on the system. That user can also interact with files and directories as if it has the most permissive permissions available.
Even if the user can’t read a file but the other category can, root can read it. Similarly, if user can read the file but other can’t, root can still read the file. But if no category has read permission (not user, not group, and not other), then root can’t read the file either.
This behavior is most useful for files you don’t want to change accidentally. If write permissions are removed from all categories for a file, then not even root can change the file’s contents without changing those permissions.
With a basic understanding of how file permissions work in Linux, you are better prepared to secure files from accidental or malicious harm. You can also keep an eye out for errors that are caused by restrictive file permissions, such as an application being unable to write to its log (caused by having no write permission for the user that owns the process), or a web server that is unable to serve an html file (caused by having no read permission, or the directory doesn’t have execute permission).
©2020 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License