Managing File Permissions and Ownership on Linux

Because Linux is a multi-user operating system, permissions to access files, directories, and other devices are necessary to ensure that users have access only to the resources for which they can use them.

Managing File and Property Permissions on Linux is quite easy, contrary to what it seems.

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

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

• User permissions: Define the permission for the user who is the “owner” of the file, who created and maintains it;
• Group permissions: Define the permission for the user group to which the file belongs;
• Permissions for other users: Define 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 with a “-” dash.

The first three positions on the left represent the permissions for the user who owns the file. The person who creates the file is its owner.

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

The last three permissions represent the others (who are not the user who owns the resource and does not belong to the group).

So, when you try to access a resource, you are either the owner of the file, or are part of the group to which the file belongs, or you are “the others”.

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

This division covers almost every need in terms of safety.

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

How to read the ls command output

The files can be classified by their type:

• (-) Common file
• (d) Directory
• (b) Block Device
• (c) Character Device (s
• ) Socket
• (p) Pipe (conductors)
• (l) Symbolic Link

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

The definitions of reading, writing, and execution have different nuances for files and directories. See the following table:

program

**Object**	Read **(r) Write**	**(w)**	Execution **(x)**
**File**	Allows you to read the contents of the file.	Allows you to change the content of the file.	Allows you to execute the file as a	**Directory**
Allows you to list the contents of the directory.	Allows you to create, move, rename, and delete files in the directory.	It allows you to read and write files to the directory, as well as change the current directory to the directory with “cd”.

Permissions are recorded in binary form, with 12 bits for each file in the system, and these bits can be represented in octal form, according to the following figure:

Permission Bits

Special permission bits on Linux --------------------------------

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

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

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

Sticky: The special bit called a sticky bit originally made programs remain in memory even after they were finished. This made programs run faster the next time they are called. This bit when applied to directories means that only the directory owner, file owner, or root can rename or delete files in this directory.

In recent Linux and Unix implementations, this bit is no longer used to “stick it in memory”, but to prevent files that have enabled it from being deleted by users other than its owner. If enabled in a directory, this bit verifies that its content can only be deleted by the respective owners of the files contained in it, the owner of the directory himself or the root.

Logically, the administrator does not 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	—	Without access
1	001	—x	Execution Only
2	010	-w-	Written Only
3	011	-wr	Writing and Performing Only
4	100	r-	Read Only
5	101	r-x	Read and Execute Only
6	110	rw-	Read and Write Only
7	111	rwx	Reading, Writing and Performing

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

Example:

rwxr-x---rootusers 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 (---) permission for users other than the users group.

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

Thus, reading (r) will have a value of 4, recording (w) will have a value of 2, and execution will have a value of (1). Then, for each permission class - owner, group, or others - the permission values are added together, so rwxr-x---, when added together by group, they will have permission 750 (4+2+1, 4+0+1, 0+0+0).

Because special permission bits are used infrequently, and under special conditions, they are represented by the letter (s) in place of the execution (x) for the SUID and SGID bits in the File Owner and Group classes, and (t) instead of the (x) ) for the sticky bit in the Other class.

See the Example:

rwsr-x--- root users Firewall

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

It also has the SUID bit enabled (the “s” instead of “x” for the File Owner).

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

Discover the Pfsense Linux Certification Online Course!

You don’t have to memorize the permission table

Just remember that Reading permissions are always set to 4.

Write permissions are always set to 2 and execute permissions are always set to 1.

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

If you decompose each number, you will find the permissions for each class. See the following figure:

Permissions in Octets

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

Did you like it?

Share