Linux file permission concepts

  • 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.

File access

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.

Ownership basics

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.

File group

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.”).

Changing ownership

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 as root.

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 chown command

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

The user in the preceding example is the user you want to own the file, and the 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.

Note: 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 possible.

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
The chgrp command

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.

The -R option

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 following example:

chown -R user:group directoryname

The -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 chown or chgrp 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 following command:

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 chown and chgrp, as shown in the following example:

chown -h user:group link

Permissions basics

There are two parts to permissions: what someone is allowed to do with a file, and who that someone can be.

What is allowed

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 (chown, ls, 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 permission.

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 ls 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.

Who can do what

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 category

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

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

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.

Category priority

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.

Permissions plus users

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 themselves.

Why root exists

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).

Share this information: