Linux file permission commands

1. Introduction

File permissions ensures that your system remains secure and that your files are properly accessible to the right users. Linux is known for its robust security model, a key part of which is the file permission system which I am going to explain in this article.

2. File permission basics

In Linux, every file and directory belongs to three categories:

• User (u): the owner of the file.
• Group (g): users belonging to the group that the file is assigned to.
• Others (o): everyone else.

Permissions are specified for each of these three categories. Each category can have three types of permissions:

• Read (r): allows reading the file or listing the directory contents.
• Write (w): allows modifying the file or changing the directory's contents.
• Execute (x): allows executing the file (if it’s a script/binary) or entering a directory.

When you run ls -l in a Linux terminal, you get a line starting with 10 characters that represent these permissions. For example:

ls -l myfile
-rwxr-xr-- 1 alice developers 4096 Jan 01 12:00 myfile

Here's how the -rwxr-xr-- is broken down:

• First character: - means a regular file (other possibilities include d for directory, l for symlink, etc.).
• Next three characters (rwx): permissions for the user (owner).
  • r = read
  • w = write
  • x = execute
• Next three characters (r-x): permissions for the group.
  • r = read
  • - = no write
  • x = execute
• Last three characters (r--): permissions for others.
  • r = read
  • - = no write
  • - = no execute

Let's look at another example

ls -l mydirectory
drwxrwxr-x  2 accounting accounting 12 Jan  8 15:13 /accounting

Let's break down the permission string drwxrwxr-x:

• d: indicates that this is a directory.
• rwx: owner (accounting) can read, write, and execute.
• rwx: group (accounting) can read, write, and execute.
• r-x: others can read and execute (no write permission).

3. Changing permissions with chmod

The chmod command is used to change file and directory permissions. You can use either numeric (octal) or symbolic modes.

3.1 Using symbolic mode

In symbolic mode, you specify u (user), g (group), o (others), or a (all) along with + (add), - (remove), or = (set).

# Give the owner execute permission
chmod u+x myfile

# Remove write permission for group
chmod g-w myfile

# Give read permission to all (user, group, and others)
chmod a+r myfile

3.2 Using numeric (octal) mode

Numeric mode uses three digits (or sometimes four for special permissions). Each digit is a sum of 4 (read), 2 (write), and 1 (execute).

• 4 = read (r)
• 2 = write (w)
• 1 = execute (x)

For example, to give the owner read, write, and execute (7), group read and execute (5), and others read (4):

chmod 754 myfile

More examples:

• chmod 777 myfile: everyone can read, write, and execute.
• chmod 644 myfile: owner can read and write, group and others can read only.
• chmod 600 myfile: owner can read and write, no one else has any permissions.

4. Changing file owner and group

The Unix file system assigns every file and directory:

• Owner: A user.
• Group: A set of users.
• Permissions: Read, write, and execute permissions for owner, group, and others.

By default, the owner is the user who created the file, and the group is the user's primary group. However, these can be changed using chown and chgrp.

4.1 The chown command

The chown (change owner) command updates the owner of a file or directory. Optionally, it can also change the group.

# Change the owner of myfile to "bob"
sudo chown bob myfile

# Change the owner AND group of myfile in one step
sudo chown bob:developers myfile

Changing ownership for folders

Without -R: sudo chown bob myfolder changes ownership of myfolder itself but not its contents.

With -R: sudo chown -R bob:developers myfolder changes ownership of myfolder and all its contents.

4.2 The chgrp command

The chgrp (change group) command updates the group of a file or directory without changing the owner.

# Change the group only
sudo chgrp developers myfile

Suppose you have a directory /var/www/mywebsite owned by root:root. You want to give developer team members read/write access to update the website.

1. Change owner: assign ownership to a designated user (e.g., bob).

   sudo chown -R bob /var/www/mywebsite

   Before changing the owner: only root could modify files in /var/www/mywebsite.

   After changing the owner: bob can now edit, remove, and set permissions.

2. Change group: assign the group to developers.

   sudo chown -R bob:developers /var/www/mywebsite
   # OR
   sudo chgrp -R developers /var/www/mywebsite
                 

   Before changing the group: the group was root, so only system administrators had access.

   After changing the group: members of developers group can collaborate.

5. Special file permissions

Beyond the basic permissions, Linux has three special permissions bits: setuid, setgid, and the sticky bit.

The setuid bit

When the setuid bit is set on an executable file, any user who runs that file temporarily gets the file owner’s privileges. A common example is /usr/bin/passwd.

ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root ...

Notice the s in the owner’s execute position (rws). If you want to set setuid on a file you own:

chmod u+s myfile

The setgid bit

Similar to setuid, the setgid bit grants the file’s group privileges to those who run the file. When set on a directory, any new files inside that directory automatically inherit the group of the directory.

# Set the setgid bit on a directory
chmod g+s mydir

Sticky bit

The sticky bit is typically used on directories (e.g., /tmp), ensuring that only the file owner (or the root user) can delete or rename the file within that directory, even if others have write permission to the directory.

# Set the sticky bit
chmod +t mydir

# Check sticky bit (it shows a 't' in the others' execute position)
ls -ld mydir
drwxrwxrwt 2 bob developers 4096 Jan 01 12:00 mydir

6. Using umask to control default permissions

Every time you create a new file or directory, the system decides its default permissions based on the umask (user file-creation mask). The umask value is subtracted from the system-wide default permissions (often 666 for files, 777 for directories).

# View the current umask
umask

# Set a new umask (e.g., 022)
umask 022

- umask 022 means new files will have permissions of 644 (666 - 022) and new directories will have 755 (777 - 022).

7. Practical examples

7.1 Example 1: securing a private document

1. Create a file secret.txt containing confidential information.
2. Ensure only you (the owner) can read/write it, and no one else can access it.

# 1. Create the file
echo "Top secret content" > secret.txt

# 2. Remove all permissions for group and others
chmod go-rwx secret.txt

# Confirm the permissions
ls -l secret.txt
# Should show something like: -rw-------

7.2 Example 2: setting a shared group directory

1. Create a group projectgroup and add users to it.
2. Create a directory project_docs, set its group to projectgroup, and set the setgid bit.
3. All files created within will belong to projectgroup automatically.

# 1. Create the directory
mkdir project_docs

# 2. Assign it to projectgroup
sudo chown :projectgroup project_docs

# 3. Set the setgid bit
chmod g+s project_docs

# Now any file created by a member in project_docs will have projectgroup as its group

8. Access Control List (ACL)

In a Linux system, traditional file permissions (read, write, execute for owner, group, and others) might not always give you the flexibility you need to grant access. That’s where Access Control Lists (ACLs) come in.

8.1 What Are ACLs?

An Access Control List (ACL) is a list of permissions assigned to specific users or groups for a file or directory.

ACLs extend the basic file permission model by allowing you to add specific rules for users and groups beyond the default owner and group. With ACLs, you can:

• Grant or revoke permissions for multiple users or groups without altering file ownership.
• Set default ACLs on directories so that newly created files/subdirectories inherit those ACLs.
• Fine-tune access to exactly the level of detail you need.

To use ACLs, you should that confirm your filesystem is mounted with acl support. Check it by running:

mount | grep acl

If you don’t see acl in the mount options, you may need to update /etc/fstab and remount:

sudo mount -o remount,acl /your/mount/point

Also, ensure the acl package is installed. On Debian-based systems:

sudo apt-get install acl

On RHEL/CentOS-based systems:

sudo yum install acl

8.2. Basic ACL commands: getfacl and setfacl

Two primary utilities manage ACLs:

• getfacl: displays the current ACLs of a file or directory.
• setfacl: sets, modifies, or removes ACL entries on a file or directory.

8.3 Viewing ACLs with getfacl

By default, ls -l does not show detailed ACL entries (though it may show a + sign to indicate ACLs are present). To see all ACL entries, use:

getfacl /thesis

If you only see user::rwx, group::rwx, and other::---, that means no additional ACL entries exist yet.

8.4 Modifying ACLs with setfacl

The typical usage of setfacl is:

setfacl -m [rule] [file or directory]

Where a [rule] might look like:

• u:username:rwx (Grants a specific user read, write, execute permissions).
• g:groupname:rx (Grants a specific group read and execute permissions).

Use -x to remove a specific ACL rule, and use -b to remove all ACL entries.

8.5 Practical examples and use cases

Adding a default ACL

Let’s say we want to ensure all new files created in /thesis inherit certain permissions. We can add a default ACL like so:

# Give the 'thesis' user (or service user) full permissions by default
setfacl -d -m user:thesis:rwx /thesis

Now, using getfacl /thesis, you’ll see entries like:

default:user::rwx
default:user:thesis:rwx
default:group::rwx
default:mask::rwx
default:other::---

Any new file in /thesis created by any user will automatically grant thesis these permissions.

Granting a specific user access

Imagine you have a student named Bob who needs to see the files inside /thesis, but doesn’t need full write permissions on the folder. You can modify the ACL for that specific user:

# Give Bob read and execute (r-x) on /thesis
setfacl -m u:bob:r-x /thesis

# Verify
getfacl /thesis

This ensures Bob can list and read the contents, but cannot create new files inside /thesis.

Allowing a user to create files in a dedicated subfolder

We want Bob to have his own folder within /thesis, where he can create new files, but still not interfere with the main thesis directory.

# Create Bob's folder and assign ownership
mkdir /thesis/bob
chown bob:thesis /thesis/Bob

# Verify ACL
getfacl /thesis/bob

By default, because Bob is the owner, he’ll have rwx on that folder. If the thesis group also has default permissions, members of that group can see or write to it—depending on the default or explicit ACL rules.

Restricting access even to the owner group

If you decide the thesis group should not see Bob’s folder, you can remove group perms:

# Remove group read, write, and execute from Bob folder
chmod g-rwx /thesis/bob

# Or use setfacl to deny the group specifically
setfacl -m g:thesis:- /thesis/bob

This way, the group ownership remains thesis, but effectively has no rights in that folder.

Giving another user access

Suppose a reviewer, Lisa, isn’t part of the thesis group but needs to review Bob’s files. You can grant her explicit ACL rights:

# Create Lisa's account (if not already existing)
useradd lisa

# Now give Lisa read/write/execute (rwx) in /thesis/Bob
setfacl -m u:lisa:rwx /thesis/Bob

Lisa can now create or modify files in Bob’s folder, even though the folder is owned by Bob and the group is thesis (with no access).

Removing specific ACL entries

If you need to remove Bob’s ACL entry for some reason, you can do:

setfacl -x u:bob /thesis

This removes the specific ACL entry for Bob on /thesis. If you want to revert the directory back to purely traditional permissions, removing all ACLs is done with:

setfacl -b /thesis

8.6 Interaction with traditional permissions

Remember that ACLs extend the traditional owner/group/other model, not replace it entirely. The mask in ACLs defines the upper limit of permissions for named users or groups. If the mask is more restrictive than an ACL entry, the effective permission will be the intersection of both.

Also note that if you remove the group’s rwx bits using chmod, it will impact any group ACL entries unless you specifically override them with new ACL entries.

9. Conclusion

In many environments, the traditional rwx permissions for owner, group, and others are enough. However, as soon as you have a complex organization (multiple users, e.g., students, supervisors, etc), you may need more nuanced access controls. Linux ACLs fill this gap:

• They allow you to grant or restrict access without changing file owners.
• They help you control exactly which users or groups have r, w, x permissions, even if they aren’t the primary group owner.
• They can set default ACLs to automatically inherit permissions in newly created subdirectories and files.