Chapter 2 - Linux as a multi-user operating system Linux was designed as a very flexible and scalable operating system. The entire architecture for kernel and distributions was planned to be used by many users. Thus, supporting concurrent access, resource and process management was considered “a must” a long time ago. One of the key features presented in the previous chapter was the fact that a box running Linux can be used concurrently by multiple users. This document will present the concepts of users, groups and the way that access to resources is limited. First of all, a multi-user operating system is a OS that can provide access for multiple users to a computer. This is a simple and straightforward definition. However, Linux can offer concurrent access for multiple users through terminals or via remote-access sessions. Basically, multi-user means that multiple users can work on the same machine. If that machine is not accessible via networking, Linux can provide multi-user access through console terminals. Now let's get back to our Linux Mint /CentOS system for some examples. On a server /desktop system you will have access to 6 terminals, accessible through the CTRL+ALT+Fx shortcuts (x can have values from 1 to 6). The eighth terminal, named tty8 will bring up the GUI in Linux Mint (or tty1, the first terminal, for Centos 6), but only if the system has a GUI installed. The other terminals will provide command line access. Press the CTRL+ALT+F2 to get access to second terminal console.
To get back to eighth terminal (GUI on a Desktop system) just press CTRL+ALT+F8. It is simple to switch between terminals using the shortcuts presented. Note that on a system initialized in runlevel 3 (usually a server), all consoles will provide just CLI access. Most of the computers are accessible through network also. Services like ssh or telnet can provide CLI (Command Line Interface) access to the system for multiple users. To see the
users currently connected on the system you can use the who command (w command works in a similar way also).
Why do we have users in Linux? Well, one of the main reasons is identifying real users and restricting their actions inside the system. For example, Alex is using the alex account and works in the software development department, while Bob accesses accounting documents using the bob user. Well, it is obvious that alex shouldn't access bob's accounting documents. This is a simple example involving user identification and access restriction. Moreover, most of the actions performed by processes are associated with system users to implement access restrictions and for security purposes. In fact, all processes inside a Linux box are running under a certain user and group and all the actions performed by them are checked against the permissions associated with that users and group. Next paragraphs will present more details about users, groups, starting new sessions under a certain user and access rights to resources.
Users and Groups Users One of the most important concepts related to Linux administration is the user. The user represents an entity, a subject that can perform several actions in a system. Note that even if most of the time one person has one user account on a machine, there shouldn't be a strict mapping between real person and computer users. However, before being able to work as a certain user and perform actions as that user, an authentication process must be passed. Most of the time, authentication means password checking, but it possible to use some other ways
for performing this step: use private/public keys, fingerprint readers, card readers, etc. The very basic idea about system users in a Linux system is that we have a username and a password that represent an account. However, there are a lot more details associated with one user account.
login: this is the standard name for the username used when accessing an account primary group: the default group for the actions performed by the current user password: used to authenticate one user. Stored in /etc/shadow file as a hash UID (user id): number used to identify an user inside the system GID (group id): numeric id used to identify the primary group shell: the shell stared after a successful login home directory: folder owned by the user and used for storing personal files, configurations and profiles
There are few types of users that can be found in a Linux system, considering their functional role. The most important user that exists in all Linux boxes is the root. The root account is the administrator's account, with full access to all resources inside the machine, no matter what permissions are set. The administrator can perform absolutely any task on the local machine, which means that this account provides the ultimate control. Hence, note that it is critical to protect it with a strong password and change that password often. Note that the supreme purpose of an attacker is to get access to the root account. You must note few default details regarding the root account:
ROOT UID: 0 PRIMARY GROUP: root (GID=0) HOME DIRECTORY: /root SHELL: /bin/bash
Apart from the root user, we have normal users. These accounts are created to identify normal users accessing the system. One example of such user is the student account created during the “First boot” process in first chapter. After accessing the student account you can use nonadministrative software, browse the web, write text documents, etc. However, the student cannot format partitions, add user accounts, change passwords and so on, as these processes require administrative access. One important detail is that normal users are associated with a shell and have a password set for security purposes. User management is performed using commands like:
useradd – to add users usermod – change attributes of users userdel – delete users
To set a password for a new user use passwd . Note that all the commands presented here have a large number of options and switches that could be inspected using the man command. (eg. man useradd will display information about the useradd command) The following example presents how to add user usr1 to the local system, set a password for the account and inspect the details using the id command.
Please inspect the default values used by useradd when creating users and the contents of the /home folder.
For normal users, note that the shell is set to /bin/bash and one home directory with user's name is created in /home (or useradd's HOME variable).
What about the SKEL folder? Well, when creating a new user, one of the steps is creating user's home directory. This process involves more than just creating the folder in HOME base directory, but it also involves copying all the files and folders from SKEL (default /etc/skel) folder to the new home directory. Hence, any files and folders added in /etc/skel will be copied to the home directories of all new users created with the useradd command.
Good. Now we have three users in our system. Where is all that information stored? Well, there are two important files involved in user administration. We have /etc/passwd and /etc/shadow. /etc/passwd is a world-readable file and represents a set of entries separated by ':' symbol.
The fileds stand for: login, 'x' symbol replaces the password (on very old systems the has password was stored here), UID, GID, comment, home directory and shell. Pay attention to the shell field. Users created for accessing the system have a shell like /bin/bash (possible other shells can be /bin/sh, /bin/csh, etc.). However, there is an important list of users that have a /sbin/nologin value in this field. Moreover, I don't remember creating any of these users at some point, so what's happening? Those users are created to restrict access to system resources for software components using the standard permissions of Linux. For example, the SSH server (sshd) can be started as sshd user (UID 74 in the output), thus having only the privileges of the sshd user all around the system. The other option is to start sshd as root, but if the sshd process is compromised, that process could run code as root. And do you remember that root has full access to the system? This is why these system users exists inside a Linux system and they cannot be used for running shell commands, as they have a “ghost” shell set, the /sbin/nologin. Cool. But where is the password stored? For this we have another file. It is the /etc/shadow. Remark that the /etc/shadow has absolutely no rights for anyone (remember that root can do anything and bypass the permissions, right?). Here we have details related to passwords associated with users. Let's check them out.
First field represents the login associated with that entry. The second field is the hash of the password. The next number represents the date when the password was last changed in days from 1st January 1970. The following two fields are the minimum and maximum days between password changes intrevals (default values are set to 0 and 99999). The 6th field represents the number of days before the password expiration date when the alert for this event is displayed. Field number 7 represents the number of days the account is disabled after the password expires and check that the default behavior means that the account cannot be used for an indefinite interval. Last value can represent a date when the account will be disabled (still days from 1st January 1970). As you can see, /etc/shadow contains information related to passwords, aging and locking. You can configure aging details using the chage command, while passwd can provide a simple interface for password expiring, locking and unlocking. Check the chage dialog presented below:
Here we have examples for locking/unlocking and expiring passwords:
To un-expire a password just set a new password for usr1 user using the passwd usr1 password. Note that the usr1 user will still be able to login but he will be prompted to change the password after the successful login.
The recommended procedure for creating a new user is presented bellow: 1. create the user: useradd myuser 2. set a default password for that user: passwd myuser 3. expire the default password to force the real user to change the default password: passwd -e myuser Note that on CentOS releases prior to version 6.3 the passwd -e command is unavailable. Use chage -d 0 myuser.
Groups A group represents a set of users. You have already learned about the primary group, which is the group associated with one user's actions. In Linux we have groups for several reasons:
easier management: assign privileges to a group of user at once, not to individual users through multiple operations group users by their purposes: users from accounting department can create files under the group the special group assigned to the department and the files will be shared to the other members instantly
With default settings, note that when you create a new user an additional group with the same name as user's login will be created and set as the primary group. If you want to create a new group, just use the groupadd command and the empty group will be created. However, to add one user to an existing group you should use the usermod command, as we are supposed to change some one of the user's attributes: group membership. The command used to append a new group to some user's group membership list is: usermod -a -G Remark the -a flag which tells the command to perform appending to the existing group membership list. Check the commands below:
Details about system users are defined in /etc/passwd and /etc/shadow. There are two similar files for groups also. Let's check /etc/group file first. Here you sill find 4 fields with the following meanings: group name, password hash (not used anymore), group ID and the list of group members.
Passwords for groups can be used for allowing users to join a group only after entering the correct password. Although not used anymore today, it is possible to set group administrators. The administrative details for groups are stored in /etc/gshadow. Here we have again four fields: group name, password hash (or ! if not set), list of group admins and list of group members.
Before moving on to switching identities we should discuss one important subject. When one user is working in a shell (no matter that it is graphical or a pure terminal), it performs actions under an identity. The identity is defined by the following details:
the currently working user ID, which identifies the user the currently working group ID, which is set as the default group for the user's actions. One important note here: when starting a shell, one user will have his GID set to the GID of the primary group (the one listed in /etc/passwd). However, it is possible to set the currently working GID to another group's GID, as you will see in the next paragraphs the list of other groups of the user
Why is that important? Well, for example, when accessing a file, the OS checks if the user or any of the groups that he is part of can perform that operation. However, when creating a file, that file will be owned by the user and the currently working group. To check the identity of the current user, just run the id command.
Switching identities We are going to discuss about 3 important commands for switching identities. First of all, it is the su command. The syntax for su command is:
su [] The purpose of the command is to start a new session as the user. If the argument is missing, it defaults to root. It is also possible to add a '-' to reload the environment of the new user. Basically, the su command will perform a new login and if the result is successful, it will start a new shell. Ending the shell session requires the exit command. Normal users can switch identity to other users if they know the passwords of that other user. However, root can switch to any other available user without knowing the password and this works even if there is no password set for the impersonated user. Note that each su opens up a new session which should be closed by an exit. Now we know how we can switch users and escalate privileges (means switching the user identity to root). But how about changing the current working group? For this task we have the sg command with the following syntax: sg If the user issuing the command is already part of that group, the command will go on silently. However, it can also be used to join groups on demand, if a password is set by an administrator for that group. It can be useful to switch groups when you need to create files that should be shared with other members of that group. Check the importance of switching group identities in the example presented below. First, usr1 logs in and works under his primary usr1 group. However, files created with touch command are group-owned by usr1. If we want to create them with friends group-ownership we have to use sg.
Sudo is the last command discussed under this topic. Sudo allows users to execute commands as root without knowing the root's password. Using sudo is very simple and it should be called by a normal user like this: sudo For example, to update the software packages using yum, execute: sudo yum update If you execute this command as a normal user, you will get an error related to the fact that you are not root. However, with sudo it will work. Using sudo is very simple. The more complicated part is to configure sudo. First of all, you need to install sudo, if it is not already installed: yum install sudo Than, to configure sudo, exceute visudo. This will open up a text editor where you can perform the configurations. Basically, all you need to do is to edit a text file. However, when you use visudo you will edit /etc/sudoers file, but after saving and closing the file, a syntax check will be performed. This is why it is recommended to use visudo, rather than just editing /etc/sudoers. It is obvious that configuring sudo requires root privileges. Performing basic sudo configuration is pretty simple. First, find the entry for the root user, who is allowed to run any command with administrative privileges via sudo. You can add another similar entry for usr1 user, for example. Than, check the entry for friends group, which allows any member of the friends group to use sudo.
Now usr1 can execute a system update using sudo:
Don't bother about the “Couldn't resolve host” error. It is caused by the fact that the machine is not connected to the internet. See that usr1 is asked for a password before actually executing the yum update? Well, the requested password is usr1's password. With the current
configurations, usr1 will be prompted for his password from time to time, when calling sudo. It is possible to disable the password verification with the following configuration changes (just add NOPASSWD):
For more details regarding sudo, please check the comments in /etc/sudoers (lines starting with '#').
Permissions Standard Linux permissions (also known as POSIX permissions) refer to what can a subject do with a resource. Subjects can be users working through a shell, processes, etc. and while objects are generally represented as files (real or virtual) or folders. In fact, There are 3 main permissions (read, write, execute) which have different meanings for files and folders. Now the basic permissions are clear. Each resource has three sets of permissions: for the owner user (u), for the owner group (g) and for the all other users (o). To see information about permissions and ownership let's check the output of a ll (or ls -l) commands.
Let's check the previous output. The line for file1 starts with a set of 11 characters. First character is '-' for a normal file, 'd' for a directory, 'l' for a links and so on. The following 9 characters represent the permissions on that file. There are three sets of rwx permissions, with '-' marking a missing permission. rwx rwx rwx rw- r-- r-The first set represents the rights of the owner, the second one is for the group owner and the last one is set for all other users. This is called the symbolic representation because it uses 'r','w','x' characters. However, from this symbolic representation we can extract a numeric representation. Each set can be considered a three bits number, with 1 on the position where the right is enabled and 0 on the rest of the positions. rwx rwx rwx rw- r-- r-110 100 100 6 4 4 ---> 644 is the numeric representation So, how can we set permissions on a resource? Well, use the chmod command: chmod
To change the ownership of the file, use chown chown : A note on how permission works. When some user tries to do an X operation with a file (X can be read, write, execute), the permissions are checked starting with user level rules: if the user is the owner of the resource, than that set of permissions is applied and the process stops here. Than, the OS checks for the permissions accorded to the groups of the user: can anyone of that group perform X? If the answer is yes, than X is permitted. If not, the rules for the others are checked and applied. Let's take the following example:
file: text.txt user owner: usr1 group owner: friends (usr1 and usr2 are the members of friends group)
Permissions: r-- rw- --Usr1 tries to write data in text.txt → the rule from owner set is applied (r--), so the action is denied, even if the group friends is allowed to do write operations. The specific user-level rule is applied and than the evaluation process stops. Usr2 tries to write data in text.txt → the group level rule is applied, the action is permitted Student tries to write data in text.txt → the other set is applied (---), and the action is denied Any problem with standard POSIX permissions? Well, they are not quite as granular as we want. We can set only one user-level rule, one group-level rule and another rule for all the other users. When this is not enough, we need to move on and use file access control lists (FACL). File access control lists (FACL) FACL technology allows administrator to add permissions for more specific users (not only the user owner) and groups. Thus we have a set of rules: user-level rules, group-level rules and finnally the others' rule. The evaluation of rules uses the same mechanism as for the POSIX permission:
if the subject has a specific rule in the user-level set, that rule is applied and the process stops if there is no user-level rule, the group-level rules are evaluated: do we have rules for the groups containing the subject? If ies, we just check if any of that group can perform the operation if we don't have any rule for the specific subject or for groups containing the user, the OS applies the permissions set for others.
There are two important commands used for controlling FACLs. To read the access list of a resource, use:
getfacl To modify or add an ACL entry, use setfacl with -m option. This option requires a value composed from 3 parts, separated by a ':'. The first part represent the type of rule: user-level (u) or group-level (g) and it is followed by the name of the user or group. The third part is the set of permissions allowed. Example: setfacl -m u:usr1:rw new_file To delete an ACL entry, use the -x option of setfacl like: setfacl -x u:usr1 new_file However, if you will list the file details after attaching an ACL you will notice a '+' following the rights column. That signifies that an FACL is attached. Once attached, the ACL will stay there, until it is completely destroyed with the -b option of setfacl. setfacl -b new_file Check the following examples of using File Access Control Lists:
As a general observation: to set permissions or change ownership of a file/folder, you need to be the owner or the root of the system. Note that in order to use FACL the “acl” mounting option must be active. If you get an “Operation not supported” error, try to remount the partition storing that resource with “acl” option on.
