Table of Contents
Introduction
Working on Linux through the command line means you constantly interact with users, permissions, and ownership. Every file, every directory, and every process is tied to a user and usually to a group. Understanding this model is essential if you want to control who can do what on a system, protect your own data, and avoid breaking things that belong to the system or other users.
This chapter gives a conceptual overview of users, groups, permissions, and ownership in Linux, and shows how they fit together at a practical level. Details of specific commands and subtopics are explored in the dedicated sections that follow in this part of the course.
The Linux multiuser model
Linux is designed as a multiuser operating system. Even if you are the only human using your computer, the system still behaves as if many users might be present. There are normal user accounts for people, accounts for system services, and a special superuser account called root.
Every file and process on the system runs “as” some user identity. This identity determines which operations are allowed. For example, a text editor running under your user cannot arbitrarily modify protected system files, but system management tools running with elevated privileges can.
The multiuser model has two main goals. It isolates users from each other so that one user cannot easily interfere with another user’s files, and it separates normal activities from administrative tasks so that accidental mistakes by an ordinary user do not damage the entire system.
Users, groups, and identities
In Linux, every user account has a numeric identifier and usually a textual name. The numeric form is the user ID, written as UID. The name is what you normally type and see in prompts, like alice or bob. Internally, Linux uses the UID to make decisions, while the name is a human friendly label.
Groups work in a similar way. A group is a collection of users that can share access to files and resources. Each group has a numeric group ID, written as GID, and a group name such as developers or students. A single user can belong to one primary group and multiple supplementary groups. When you create or edit files, both a user and a group are attached to those files.
There is a special user account called root with UID 0. This account bypasses almost all permission checks and can perform any operation on the system. Normal users do not have these abilities by default. Gaining temporary administrative power is often done through sudo, which you will learn about in a later section.
Ownership of files and processes
Every file and directory has two owners in Linux. The first is the owning user, and the second is the owning group. When you list files, you can see both of these. The ownership determines which permission entries apply to you, and which ones apply to other users in your group or to everyone else.
User ownership is typically assigned based on the user who created the file. Group ownership usually follows the user’s primary group at the time of creation, although it can be changed and can be influenced by directory settings. Changing ownership of files is possible, but ordinary users are limited in how they can do it. Administrative tools can transfer ownership in more flexible ways.
Processes, like running programs or services, also run with an associated user and group. A process inherits the identity of whoever started it, unless it is specifically configured to run with a different identity. This is an important security feature, because a process can only act on files and resources according to its user and group permissions.
Permissions as access rules
Permissions in Linux are a set of access rules attached to each file and directory. These rules decide whether a given user or group can read, modify, or execute that file or enter that directory. There are three main classes of subjects for permissions. The owner refers to the specific user that owns the file. The group refers to users that belong to the owning group. Others refers to everyone else on the system.
Within each of these classes, Linux tracks three fundamental permission bits. Read permissions control viewing file contents or listing a directory’s entries. Write permissions control modifying file contents or altering directory contents. Execute permissions control running a file as a program or entering a directory and accessing items inside it.
Permissions are checked in order. First Linux checks whether the running user is the file’s owner. If so, the owner bits apply. If not, it checks whether the user is in the file’s group, and if so, the group bits apply. If neither is true, the “others” bits are used. Only one class applies per access attempt.
Linux access control for standard permissions always follows the order: owner, then group, then others. Only the first matching class is used for the decision.
Numeric representation of permissions
Although permissions are often shown using letters like r, w, and x, they also have a numeric form. Each of the three basic permissions is mapped to a bit value. Read corresponds to 4, write to 2, and execute to 1. For each class of owner, group, and others, the three bits are combined by addition.
For example, a permission set of read and write but no execute corresponds to the number $4 + 2 = 6$. Full permissions read, write, and execute correspond to $4 + 2 + 1 = 7$. Having only read and execute without write corresponds to $4 + 1 = 5$.
A full permission string is often written as three digits. The leftmost digit is for the owner, the middle for the group, and the rightmost for others. So 640 means read and write for the owner, read only for the group, and no permissions for others. Similarly, 755 means full permissions for the owner and read plus execute for group and others.
The basic numeric mapping is:
read = 4, write = 2, execute = 1, and the sum for each class forms a digit in the three digit permission code.
The root user and privilege separation
The root account is a central concept in Linux permissions. Root, with UID 0, is treated as trusted code inside the system and is allowed to override almost every permission restriction. This capability exists so that system administration is always possible, even if permissions get misconfigured.
For everyday work, however, using root directly is discouraged. Running commands as root for normal tasks increases the risk that a simple mistake can remove or damage important system files. The safer pattern is to work as an unprivileged user and temporarily elevate permissions for specific administrative actions.
The tool that allows this on most modern Linux systems is sudo. It lets selected users run certain commands with root privileges without giving them full root access all the time. Precisely how to use sudo and how it relates to authentication is discussed separately in a later part of this section.
Security implications of permissions and ownership
Permissions and ownership form the front line of local security on a Linux system. Correctly assigned ownership ensures that files belong to the right user and group, and that only authorized people can read or modify them. Well chosen permission combinations prevent accidental or malicious changes.
For personal systems, a typical pattern is to give your own files relatively strict permissions, so that only you can read and write them, while leaving shared or public data more accessible if needed. For servers, file and directory permissions are an important part of hardening services so that they cannot be easily misused in case of vulnerabilities.
Because Linux is used in multiuser environments, mistakes like giving write permissions to “others” on a critical file can have serious consequences. Understanding how users, groups, and permission bits interact is therefore not only about convenience, but is also a foundation for safe system administration.
How these concepts fit into practical work
Day to day, you will see this permission and ownership model in many places. Listing the contents of directories shows you who owns each item and what access they have. Creating and editing files attaches your user identity so the system knows they are yours. Running commands that require system level changes often triggers a request to elevate privileges through sudo.
Later sections will show how to inspect users and groups, interpret permission strings, modify permission bits, change ownership where appropriate, and safely use administrative privileges. With the conceptual framework from this chapter in mind, those commands and techniques will fit into a clear picture of how Linux controls access across the entire system.