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 non-
administrative 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 <login> . 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 <groupname> 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 <group> <login>

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 [<login>]

The purpose of the command is to start a new session as the <login> user. If the <login>
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 <groupname>

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 <command to be executed as root>

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 <numeric_permissions> <file/folder>

To change the ownership of the file, use chown

chown <new_user_owner>:<new_group_owner> <file/folder>

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 <file/folder>

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.