File Permissions in Linux: chmod, chown, umask and ACLs

Since Linux is a multi-user operating system, file, directory, and other device access permissions are necessary to ensure that users only have access to the resources they are authorized to use. 

Managing File Permissions and Ownership in Linux is quite easy, contrary to what it may seem.

These resources can range from a simple file to a printer or a CD-ROM burner. 

Each file in Linux has its access control defined. This control is defined by three classes:

• User permissions: Defines the permission for the user who is the file "owner," who created and maintains it;
• Group permissions: Defines the permission for the group of users to which the file belongs;
• Other users permissions: Defines the permission for all other users (not the owner and not part of the group). 

Permission Classes

And for each class we can define three types of access: read (r), write (w), and execute (x). When there is no access for that particular type, the system signals it with a dash "-".

The first three positions from the left represent the permissions for the owner user of the file. The one who creates the file is its owner.

The next three represent the permissions relative to a group (the owner user may or may not belong to the group).

The last three permissions represent others (who are not the owner user of the resource and do not belong to the group).

So, when trying to access a resource, either you are the file owner, or you belong to the group the file belongs to, or you are "others".

Since in Linux everything is a file, this makes working with permissions much easier, since the scheme is the same for everything. It doesn't matter if you are talking about a file, directory, or hardware resource.

This division covers practically all needs in terms of security.  

The "-l" option of the ls command shows file permissions:

How to read the ls command output

Files can be classified by their type:

• (-) Regular file
• (d) Directory
• (b) Block device
• (c) Character device
• (s) Socket
• (p) Pipe (named pipe)
• (l) Symbolic link

The first letter that appears on the left of "ls -l" indicates the file type. When there is no letter, but a dash, the file is regular.

The definitions of read, write, and execute have different nuances for files and directories. See the table below:

Object	Read (r)	Write (w)	Execute (x)
File	Allows reading the file's content.	Allows modifying the file's content.	Allows executing the file as a program
Directory	Allows listing the directory's contents.	Allows creating, moving, renaming, and deleting files in the directory.	Allows reading and writing files in the directory, as well as changing the current directory to the directory with "cd".

Permissions are stored in binary form, with 12 bits for each file in the system, and these bits can be represented in octal form, as shown in the following figure:

Permission Bits

Special Permission Bits in Linux

The first three bits from left to right are special attribute bits, namely:

SUID (Set User ID): The SUID bit affects only executable files. Normally programs are executed with the permission of the user who ran them. SUID changes this condition, causing the program to be executed under the permissions of the file Owner user, regardless of who called it. SUID is generally used to give a program root permissions. Administrators must be very careful when using SUID, as a malicious program may gain elevated access to the system;

SGID (Set Group ID): The SGID bit works like the SUID bit. It causes programs to execute under the group permission of the file owner. If applied to a directory, SGID will cause all files created under that directory to have the same group as the directory;

Sticky: The special bit called sticky or save-text bit originally caused programs to remain in memory even after they finished. This made programs execute faster the next time they were called. When this bit is applied to directories, it causes only the directory owner, the file owner, or root to be able to rename or delete files in that directory.

In recent implementations in Linux and Unix this bit is no longer used to "save text in memory," but to prevent files that have it enabled from being deleted by users who are not their owner. If enabled in a directory, this bit ensures that its contents can only be deleted by the respective owners of the files contained in it, the directory owner itself, or root.

Of course, the administrator doesn't need to write permissions in 12 bits. Thus, permissions can be represented by letters or in octets according to the following table:

Octal	Binary	Letters	Description
0	000	---	No access
1	001	--x	Execute only
2	010	-w-	Write only
3	011	-wx	Write and Execute only
4	100	r--	Read only
5	101	r-x	Read and Execute only
6	110	rw-	Read and Write only
7	111	rwx	Read, Write and Execute

This representation can be used for each class (Owner, Group, and Others), as well as for special bits (SUID, SGID, Sticky).

Example:

rwxr-x---	root	users	Script.sh

In the example, the Script.sh file has read, write and execute (rwx) permissions for the root user, read and execute (r-x) permissions for the users group, and no (---) permissions for other users who are not in the users group. 

The permissions of the Script.sh file can be represented by the octets 750, being 7 (4+2+1) for the file owner's permissions (rwx), 5 (4+1) for the Group's permissions (r-x) and 0 (---) for Others' permissions.

Thus, read (r) will have the value of 4, write (w) will have value 2, and execute will have value (1). So, for each permission class - owner, group, or others - you add up the permission values, so that rwxr-x---, when summed by group, will have the permission 750 (4+2+1, 4+0+1, 0+0+0).

Since special permission bits are used infrequently and under special conditions, they are represented by the letter (s) in place of the execute (x) for SUID and SGID bits in the file Owner and Group classes, and (t) in place of the (x) for the sticky bit in the Others class.

See the Example:

rwsr-x--- root users Firewall

The Firewall file has read, write, and execute permissions (rws) for the root user, read and execute (r-x) for users in the users group, and no permissions (---) for Others.

And it also has the SUID bit enabled (the "s" in place of "x" for the file Owner).

Thus, the Firewall program has superuser powers when executed, since its owner is root. Its permissions can also be represented by the octet 4750.

Check out the Pfsense Online Course from Certificação Linux!

You don't need to memorize the permissions table

Just remember that Read permissions always have the value 4.

Write permissions always have the value 2 and execute permissions always have the value 1.

The three permission classes (Owner, Group, and Others) are represented by 3 numbers.

If you break down each number, you will find the permissions for each class. See the figure below:

Permissions in Octets

Learn much more about Linux in our online course. You can enroll here. If you already have an account, or want to create one, just log in or create your user here.

Liked it? Share