Permissions
Chapter 09
Unix-based operating systems diverge from MS-DOS-based ones by being both multitasking and multi-user systems.
What does this signify? It implies that multiple individuals can operate the computer simultaneously. Despite typically having just one keyboard and monitor, multiple users can access it. For instance, if a computer is connected to a network or the Internet, remote users can log in through SSH (secure shell) and use the computer. Moreover, remote users can run graphical applications and view the graphical output on a remote display. The X Window System accommodates this within its fundamental structure.
Linux's ability to support multiple users isn't a recent novelty; it's intricately woven into the operating system's design. This design choice aligns with the era when Unix emerged. Back then, computers weren't "personal"; they were sizable, costly, and centralized. University computer systems, for instance, had a main central computer in one building and terminals scattered across the campus, all linked to this central unit. Consequently, these computers accommodated numerous users concurrently.
To ensure practicality, a system had to be created to safeguard users from each other. It was crucial to prevent one user's actions from crashing the computer or meddling with the files of another user.
In this chapter, our focus will be on examining this fundamental aspect of system security and presenting the subsequent commands:
id– Display user identitychmod– Change a file's modeumask– Set the default file permissionssu– Run a shell as another usersudo– Execute a command as another userchown– Change a file's ownerchgrp– Change a file's group ownershippasswd– Change a user's password
Owners, Group Members, And Everybody Else
During our exploration of the system in Chapter 3, we might have faced an issue while attempting to inspect a file like /etc/shadow:
This error occurs because, as regular users, we lack the permission to read this file.
Within the Unix security framework, users possess ownership of files and directories, thereby controlling their accessibility. Users can also be part of a group, enabling multiple users access as permitted by the owners. Furthermore, an owner can grant specific access rights to everyone, known in Unix as the "world". To retrieve details about your identity, utilize the id command:
Consider the output: When user accounts are generated, users receive a numerical designation referred to as a user ID or uid, which is then translated into a username for human readability. Additionally, users are allocated a primary group ID or gid and can be part of supplementary groups. The provided example is from a Fedora system; however, on alternate systems like Ubuntu, the output might appear slightly distinct.
The disparity in uid and gid numbers arises because Fedora initiates its numbering for regular user accounts at 500, whereas Ubuntu commences at 1000. Moreover, the Ubuntu user is affiliated with a greater number of groups, influenced by Ubuntu's method of administering privileges for system devices and services.
This information stems from a couple of text files, as is often the case in Linux. User accounts find definition in the /etc/passwd file, while groups are outlined in the /etc/group file. As user accounts and groups are established, these files undergo modifications, alongside the /etc/shadow file that stores password-related details. Within the /etc/passwd file, each user account specifies the login name, uid, gid, the account's actual name, home directory, and login shell. Examining the contents of /etc/passwd and /etc/group reveals not only regular user accounts but also entries for the superuser (UID 0) and various other system users.
In the upcoming chapter on processes, you'll discover that some of these additional "users" are notably active.
While numerous Unix-like systems allocate regular users to a shared group like "users," contemporary Linux methodology involves establishing an exclusive, solitary-member group bearing the user's name. This simplifies certain permission allocation procedures.
Reading, Writing, And Executing
File and directory access privileges are delineated through read, write, and execute permissions. Examining the output of the ls command provides insight into how this is executed.
The initial ten characters within the listing denote the file attributes, with the first character representing the file type. These are the common file types you'll typically encounter (although there are rarer types as well):
-
A regular file.
d
A directory.
l
A symbolic link. Notice that with symbolic links, the remaining file attributes are always “rwxrwxrwx” and are dummy values. The real file attributes are those of the file the symbolic link points to.
c
A character special file. This file type refers to a device that handles data as a stream of bytes, such as a terminal or modem.
b
A block special file. This file type refers to a device that handles data in blocks, such as a hard drive or CD-ROM drive.
The subsequent nine characters within the file attributes, known as the file mode, signify the read, write, and execute authorizations for the file's owner, the group owner, and all other users:
rwx
rwx
rwx
When set, the r, w, and x mode attributes have the following effect on files and directories:
r
Allows a file to be opened and read.
Allows a directory's contents to be listed if the execute attribute is also set.
w
Allows a file to be written to or truncated, however this attribute does not allow files to be renamed or deleted. The ability to delete or rename files is determined by directory attributes.
Allows files within a directory to be created, deleted, and renamed if the execute attribute is also set.
x
Allows a file to be treated as a program and executed. Program files written in scripting languages must also be set as readable to be executed.
Allows a directory to be entered, e.g., cd directory.
Here are some examples of file attribute settings:
-rwx------
A standard file that grants read, write, and execute permissions solely to the file's owner, with no access permitted for anyone else.
-rw-------
A typical file that allows read and write permissions exclusively for the file's owner, with no access granted to anyone else.
-rw-r--r--
A standard file that permits read and write privileges solely for the file's owner, allows members of the file's owner group to read the file, and is accessible to everyone.
-rwxr-xr-x
A typical file granting read, write, and execute permissions exclusively to the file's owner, while allowing everyone else to read and execute it.
-rw-rw----
A standard file allowing read and write access solely to the file's owner and members of the file's group owner.
lrwxrwxrwx
A symbolic link possesses placeholder permissions, known as "dummy" permissions, while the actual permissions are retained by the file indicated by the symbolic link.
drwxrwx---
A directory that allows the owner and members of the owner group to enter, create, rename, and delete files within it.
drwxr-x---
A directory where the owner has permissions to access, create, rename, and delete files within it. Members of the owner group can access the directory but lack the ability to create, delete, or rename files within it.
chmod – Change File Mode
chmod – Change File ModeTo modify the mode (permissions) of a file or directory, the chmod command is utilized. It's important to note that only the file’s owner or the superuser can alter the mode of a file or directory. chmod provides two methods for specifying mode changes: octal number representation and symbolic representation. Let's begin by exploring octal number representation.
What on Earth is Octal?
Octal (base 8) and its counterpart, hexadecimal (base 16), represent number systems frequently utilized in computer language. Human counting generally operates in base 10 due to our ten fingers. However, computers, having only one "finger," utilize binary (base 2), with just two numerals: 0 and 1.
Binary counting progresses like this:
0, 1, 10, 11, 100, 101, 110, 111, 1000, 1001, 1010, 1011...
In octal, counting involves numerals zero through seven:
0, 1, 2, 3, 4, 5, 6, 7, 10, 11, 12, 13, 14, 15, 16, 17, 20, 21...
Hexadecimal utilizes zero through nine and adds the letters “A” through “F”:
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, 10, 11, 12, 13...
While binary suits computers due to their binary nature, what purpose do octal and hexadecimal serve? The answer lies in human convenience. Often, computers represent small data portions as bit patterns. Consider an RGB color; a pixel typically consists of eight bits each for red, green, and blue.
Reading and writing long binary numbers daily isn't ideal. This is where octal and hexadecimal come in. Each hexadecimal digit represents four binary digits, while in octal, each digit signifies three binary digits.
For instance, a 24-digit binary for a medium blue color (010000110110111111001101) can be condensed into a six-digit hexadecimal number (436FCD). Here, each component (red, green, blue) aligns with their respective bits.
Although hexadecimal notation is more prevalent now, octal's ability to express three binary bits remains useful...
Using octal notation involves employing octal numbers to establish the desired permission pattern. Given that each digit in an octal number denotes three binary digits, this aligns neatly with the file mode storage scheme. The following table illustrates this concept:
0
000
---
1
001
--x
2
010
-w-
3
011
-wx
4
100
r--
5
101
r-x
6
110
rw-
7
111
rwx
Using three octal digits allows us to configure the file mode for the owner, group owner, and everyone else.
With the argument "600," we adjusted the permissions for the owner to read and write, excluding all permissions for the group owner and others. While recalling the octal-to-binary mapping might appear cumbersome, you'll typically work with a few common ones: 7 (rwx), 6 (rw-), 5 (r-x), 4 (r--), and 0 (---).
chmod also incorporates a symbolic representation for defining file modes. Symbolic notation consists of three segments: identifying the target, indicating the operation, and specifying the permission to be set. To denote who is impacted, a blend of characters such as u, g, o, and a is utilized in the following manner:
u
Short for user but means the file or directory owner.
g
Group owner.
o
Short for others, but means world.
a
Short for all. The combination of u, g, and o.
When no character is specified, it defaults to all. The operation can be represented by a + to add a permission, a - to remove a permission, or a = to apply only the specified permissions while removing all others.
Permissions are indicated using the r, w, and x characters. Below are a few instances of symbolic notation:
u+x
Add execute permission for the owner.
u-x
Remove execute permission from the owner.
+x
Add execute permission for the owner, group, and world. Equivalent to a+x.
o-rw
Remove the read and write permission from anyone besides the owner and group owner.
go=rw
Set the group owner and anyone besides the owner to have read and write permission. If either the group owner or world previously had execute permissions, they are removed.
u+x,go=rx
Add execute permission for the owner and set the permissions for the group and others to read and execute. Multiple specifications may be separated by commas.
While some individuals favor octal notation, others strongly prefer symbolic notation. Symbolic notation holds the advantage of enabling you to adjust a single attribute without affecting the others.
Refer to the chmod manual page for comprehensive information and a rundown of available options. Regarding the --recursive option, a note of caution: it applies changes to both files and directories, which might not always be ideal as files and directories often require different permissions.
Setting File Mode With The GUI
Now that we've observed the process of setting permissions for files and directories, we can gain a clearer comprehension of the permission dialogs within the graphical user interface (GUI). In Nautilus (GNOME) or Konqueror (KDE), accessing the properties dialog by right-clicking on a file or directory icon provides insight. Below is an example from KDE 3.5:
In this view, the configurations for the owner, group, and world are displayed. In KDE, accessing the "Advanced Permissions" button opens a secondary dialog, enabling individual adjustments for each mode attribute. Another triumph for comprehension facilitated through the command line!
umask – Set Default Permissions
umask – Set Default PermissionsInitially, we eliminated any existing copy of foo.txt to ensure a clean start. Subsequently, running the umask command without an argument displayed the current value, indicating 0002 (alternatively, 0022 is another commonly used default value), representing the octal representation of our mask. Following this, we generated a fresh instance of the file foo.txt and examined its permissions.
The owner and group possess both read and write permissions, whereas everyone else is granted only read permission. The absence of write permission for others is due to the mask value. Let's redo our demonstration, this time configuring the mask manually:
When we disable the mask by setting it to 0000, effectively turning it off, the file becomes world-writable. Exploring this process requires revisiting octal numbers. By converting the mask into binary and comparing it with the attributes, we gain insight into the changes occurring.
Original file mode
-- rw- rw- rw-
Mask
000 000 000 010
Result
--- rw- rw- r--
For now, disregard the leading zeros (we'll address those shortly) and notice that where the 1 appears in our mask, it removes an attribute—in this instance, the world's write permission. That's the function of the mask. Whenever a 1 appears in the binary representation of the mask, it unsets an attribute. If we examine a mask value of 0022, we can discern its impact:
Original file mode
--- rw- rw- rw-
Mask
000 000 010 010
Result
--- rw- r-- r--
Once more, wherever a 1 is present in the binary representation, it cancels out the respective attribute. Experiment with different values (consider using some sevens) to become familiar with this process. Once finished, ensure to tidy up:
Usually, you won't need to alter the mask; the default provided by your distribution will suffice. Yet, in certain high-security scenarios, you may need to manage it yourself.
Some Special Permissions
Although we often encounter an octal permission mask as a three-digit number, technically, it's more accurate to express it in four digits. Why? Apart from read, write, and execute permissions, there are additional, less utilized settings.
The first is the setuid bit (octal 4000). When applied to an executable file, it changes the effective user ID from the real user to that of the program's owner. Typically granted to select programs owned by the superuser, it allows an ordinary user running a setuid root program to access files and directories restricted for regular users. Given its security implications, the number of setuid programs should be minimized.
The second less-used setting is the setgid bit (octal 2000), which, like setuid, alters the effective group ID. When set on a directory, newly created files within inherit the directory's group ownership rather than that of the file's creator. This proves beneficial in shared directories where a common group requires access to all files irrespective of the file owner's primary group.
The third is the sticky bit (octal 1000), a legacy from ancient Unix that designated an executable file as "not swappable." Though Linux disregards this on files, applying it to a directory prevents users from deleting or renaming files unless they are the directory owner, file owner, or the superuser. It's often used in directories like /tmp to regulate access.
Using chmod with symbolic notation, you can set these special permissions. For instance, assigning setuid to a program: chmod u+s program, setting setgid to a directory: chmod g+s dir, or applying the sticky bit to a directory: chmod +t dir.
When using ls, you can identify special permissions in the output:
A
setuidprogram:-rwsr-xr-xA directory with the
setgidattribute:drwxrwsr-xA directory with the sticky bit set:
drwxrwxrwt
Changing Identities
Occasionally, we might need to assume the identity of another user. This is commonly sought to acquire superuser privileges for administrative tasks. However, it's also feasible to "become" another regular user, useful for tasks like account testing. There are three methods to adopt an alternate identity:
Log out and log back in as the alternate user.
Use the
sucommand.Use the
sudocommand.
We'll pass over the initial method as it's less convenient compared to the other two options. Within our current shell session, the su command facilitates assuming another user's identity. It allows the launch of a new shell session using that user's IDs or executing a single command as that user. On the other hand, the sudo command enables an administrator to configure a file /etc/sudoers defining specific commands that certain users can execute under an assumed identity. The selection between these commands typically depends on the Linux distribution. Although your distribution may incorporate both commands, its setup will likely favor one over the other. Let's begin with su.
su – Run A Shell With Substitute User And Group IDs
su – Run A Shell With Substitute User And Group IDsThe su command initiates a shell as a different user. The command's syntax appears as follows:
When the -l option is added, the resulting shell session becomes a login shell for the designated user. This action involves loading the user's environment and switching the working directory to the user's home directory, which is typically the desired behavior. If no user is specified, it defaults to the superuser. Interestingly, the -l option can be abbreviated as -, which is the more common usage. To launch a shell for the superuser, the command would appear as:
Upon executing the command, a prompt for the superuser's password appears. Upon successful authentication, a new shell prompt emerges, denoting superuser privileges (indicated by # instead of $), and the current working directory shifts to the superuser's home directory (usually /root). Inside this new shell, commands can be executed with superuser privileges. To revert to the previous shell, simply input exit.
You can execute a single command without initializing a new interactive session by using su in this manner:
In this format, a solitary command line is transferred to the new shell for execution. It's crucial to encase the command within quotes to prevent expansion in our current shell and ensure it happens within the new shell:
sudo – Execute A Command As Another User
sudo – Execute A Command As Another UserThe sudo command, akin to su in many aspects, offers significant additional functionalities. An administrator can set up sudo to enable an ordinary user to execute commands as a distinct user, often the superuser, in a highly controlled manner. Specifically, a user might be limited to one or more specific commands while being restricted from executing others. Another notable distinction is that sudo usage doesn't necessitate the superuser's password; instead, the user employs their own password for authentication.
For instance, suppose sudo is configured to permit the execution of a hypothetical backup program named backup_script, which demands superuser privileges. Using sudo, it can be accomplished as follows:
Upon entering the command, we're prompted for our password (not the superuser's). Once the authentication is successful, the specified command is executed. An important contrast between su and sudo lies in sudo's operation—it doesn't initiate a new shell or load another user's environment. Consequently, commands do not require any different quoting compared to when sudo is not in use. However, this behavior can be altered by specifying different options. Refer to the sudo man page for comprehensive details.
To see what privileges are granted by sudo, use the -l option to list them:
Ubuntu And sudo
sudoOne persistent issue for regular users involves executing tasks that demand superuser privileges, such as software installations, system configuration modifications, and device access. In the Windows environment, users often acquire administrative privileges, enabling them to perform these tasks. However, this also grants the same abilities to programs executed by the user, paving the way for potential malware like viruses to exploit the system freely.
In the Unix realm, owing to its multiuser legacy, there's a clearer distinction between regular users and administrators. The Unix approach involves granting superuser privileges only when necessary, commonly facilitated by the su and sudo commands.
In the past, most Linux distributions relied on su for this purpose, as it didn't demand the configuration required by sudo, and having a root account aligns with Unix tradition. However, this led to a problem—users often operated unnecessarily as root, seeking to avoid "permission denied" messages. Unfortunately, this significantly reduced the security of Linux systems, comparable to Windows systems—a risky practice.
Ubuntu, upon its introduction, pursued a different approach. By default, Ubuntu prohibits logins to the root account (by not setting a password for the account) and, instead, utilizes sudo to confer superuser privileges. The initial user account receives full access to superuser privileges via sudo and can grant similar powers to subsequent user accounts.
chown – Change File Owner And Group
chown – Change File Owner And GroupThe chown command facilitates altering the owner and group owner of a file or directory. Using this command necessitates superuser privileges. The syntax for chown appears as follows:
chown has the capability to modify either the file owner, the file group owner, or both based on the initial argument provided in the command. Below are a few examples:
bob
Changes the ownership of the file from its current owner to user bob.
bob:users
Changes the ownership of the file from its current owner to user bob and changes the file group owner to group users.
:admins
Changes the group owner to the group admins. The file owner is unchanged.
bob:
Change the file owner from the current owner to user bob and changes the group owner to the login group of user bob.
Consider a scenario involving two users: janet, who possesses superuser privileges, and tony, who does not. Janet aims to replicate a file from her home directory into tony's home directory. To grant tony the ability to edit the file, Janet modifies the ownership of the copied file, transitioning it from janet to tony:
In this instance, user janet duplicates the file from her directory to user tony's home directory. Subsequently, janet alters the ownership of the file from root (which occurred due to the use of sudo) to tony. Employing the trailing colon within the initial argument, janet also adjusts the group ownership of the file to tony's login group, identified as the tony group:
After the initial use of sudo, janet wasn't prompted for her password. This behavior occurs because sudo, in most configurations, maintains a level of "trust" for several minutes until its timer expires.
chgrp – Change Group Ownership
chgrp – Change Group OwnershipIn earlier Unix versions, the chown command exclusively modified file ownership and not group ownership. To manage group ownership, a distinct command named chgrp was employed. Its functionality resembled chown but was more restricted in scope.
Exercising Our Privileges
Now that we've grasped the mechanics of permissions, let's put this knowledge into action. We'll illustrate the resolution to a frequent dilemma—establishing a shared directory. Picture two users named bill and karen. Both possess music CD collections and aim to create a shared directory. This space will serve as a repository for their music files in Ogg Vorbis or MP3 format. User bill holds superuser privileges accessible via sudo.
Initially, a group must be formed that includes both bill and karen as participants. Utilizing the graphical user management tool, bill establishes a group named music and includes users bill and karen as its members:
Next, bill creates the directory for the music files:
As bill is managing files outside his home directory, he needs superuser privileges. Upon creating the directory, it assumes the following ownerships and permissions:
From the observation, the directory is owned by root and holds 755 permissions. To enable sharing of this directory, bill must modify the group ownership and the group permissions to permit writing:
This setup signifies that we've established a directory, /usr/local/share/Music, possessed by root and permitting read and write access for the group music. Group music comprises bill and karen as members, granting them the capability to create files within the /usr/local/share/Music directory. While other users can view the directory's contents, they lack the permission to generate files within it.
However, there remains an issue. Under the existing permissions, any files or directories generated within the Music directory will inherit the standard permissions of users bill and karen:
There are actually two concerns here. Initially, the default umask on this system is 0022, hindering group members from writing files attributed to other group members. While this wouldn't be an issue if the shared directory solely housed files, it's problematic since this directory will contain music, typically arranged in artist and album hierarchies. Group members require the capability to create files and directories within directories established by fellow members. To address this, we need to modify the umask employed by bill and karen to 0002 instead.
Another issue arises where each file and directory generated by a user defaults to their primary group rather than the group music. To resolve this, setting the setgid bit on the directory can rectify the matter:
Let's verify if the updated permissions resolve the issue. bill adjusts his umask to 0002, eliminates the earlier test file, and generates a new test file and directory:
Now, both files and directories are produced with the appropriate permissions, enabling all group music members to generate files and directories within the Music directory.
The persisting concern lies with the umask, as the required setting remains effective only until the session concludes and necessitates a reset. In Chapter 11, we'll explore methods to establish a lasting adjustment to the umask.
Changing Your Password
We'll conclude this chapter by addressing the procedure for setting passwords for yourself (or other users, if you possess superuser privileges). To establish or modify a password, the passwd command is employed. The command's syntax appears as follows:
To alter your password, simply execute the passwd command. You'll receive prompts for both your old password and the new password:
The passwd command aims to implement the use of "strong" passwords. As a result, it will reject passwords that are too brief, closely resemble prior passwords, consist of dictionary words, or are easily predictable:
With superuser privileges, you can designate a username as an argument to the passwd command, allowing the alteration of passwords for other users. Additional options are accessible to the superuser, facilitating account locking, password expiration, and more. For detailed information, refer to the passwd man page.
Summary
Throughout this chapter, we've explored how Unix-like systems, like Linux, oversee user permissions, permitting read, write, and execution access to files and directories. The fundamental concepts of this permission structure trace back to the inception of Unix and have endured quite effectively over time. However, the innate permissions system in Unix-like systems lacks the intricate granularity found in more contemporary systems.
Last updated