Users, Processes and Permissions

Introduction

Linux is a multi-User system, allowing many Users to work on the same machine at once.
As such, we need mechanisms to separate between Users - so one User won't stumble on the work of another User.
And then we will need mechanisms which will allow Users to share their work.
Users, Processes and Permissions are the way to handle that.
Note: during this lecture, we will show examples on a live system. The examples are NOT detailed in the slides.

Once again, remember what sets off "the hitch-hikers guide to the galaxy" from "the encyclopedia Galactica": It has, written on its top, the phrase: Don't Panic!

Users

Users are identified by a User id - a number.
User ID '0' is "root" - the all-powerful administrator.
Objects in the system (Processes, Files) are attached to Users.
Everything else stems from that.
All Users are defined in the file "/etc/passwd".

/etc/passwd

Each User should have a line in this file.
(Yet, one can create Files belonging to Users not found in this file).
A line in this file is split into fields using the ':' character:
- User Name
- Password/Password's Location (empty - no password, 'x': shadowed password - appears in "/etc/shadow" instead)
- User ID (number)
- User's default Group ID (will be explained later)
- Real Name (some descriptive text)
- Home Directory
- Login Shell

/etc/shadow

Historically, passwords appeared, in encrypted format, in the "/etc/passwd" file.
However, since this file is world-readable (i.e. all Users on the system can and must be able to read it), this allowed various cracking attacks.
Thus, passwords are now stored in the file "/etc/shadow", and only the "root" User may read this file.
A line in this file is split into fields using the ':' character:
- User Name
- Password (in encrypted format).
- Various dates, used for account management.

/etc/shadow (Cont.)

In order to have a User with no password, it is enough to empty the 'password' field of the User.
Encrypted passwords cannot contain the '*' character.
Thus, to temporarily disable an account, an easy way is to add a '*' to the beginning of the password field.

Groups

Groups are identified by a Group id - also a number.
A Group may contain 0 or more Users.
Objects in the system (Processes, Files) are attached to Users.
All Groups are defined in the file "/etc/group".
Except for 'default Groups', which might be implicitly defined in "/etc/passwd".

/etc/group

Each Group (except default Groups) should have a line in this file.
(Yet, one can create Files belonging to Groups not found in this file).
A line in this file is split into fields using the ':' character:
- Group Name
- Password/Password's Location (normally not used, and containing an 'x').
- Group ID (number)
- List of Users, separated by a ',' (comma) character.

Users, Groups and Files

Every File in the system has an owner User.
When a User creates a new File - the File is owned by this User.
The File also has an "owner Group".
The owner Group, Normally, is the 'default Group' of the User...
...Except when it is not (as will be seen later on).

The File's Owner User

The User-owner of a File can always update the permissions of the File...
...Except when the User cannot access the Directory containing the File.
The User-owner of a File containing a program, might also matter when executing (= running) the File - we will see that later.

File Access Permissions

Each File has access permissions, defining which Users can use it.
A Directory is also a File - so it also has access permissions.
In order to access a File, we need access to all Directories containing the File.
e.g. to access "/etc/passwd", we need access to Directory "/", Directory "/etc" and the file "/etc/passwd" itself.

File Access Permissions - Who may access?

Access Permissions are split into 3: for the User-owner, the Group-owner and for "others".
If the User accessing the File is the User-owner of the File, only the "User-owner" permissions are checked.
Thus, a File with permissions for 'others' but no permissions for 'User-owner' - won't allow the User-owner to access it...
...But as we said, the User-owner may always change the permissions of the File, so she can give herself access to the File, and then access the File.
A similar check is performed if the User accessing the File, belongs to the Group-owner of the File (but is not the User-owner of the File).

File Access Permissions - permission to do what?

Access Permissions are further split into 3: read, write and execute.
For a File, 'read' means permission to view the contents of the File.
'write' means permission to modify the contents of the File.
'execute' means permission to execute (=run) the File, assuming it is a program.

Directory Access Permissions - permission to do what?

For a Directory, 'read' means permission to view the list of Files in the Directory.
'write' means permission to create new Files in the Directory.
'execute' means permission to access Files in the Directory.
Thus, in order to be able to read the contents of a File, the User must have 'execute' permission on all Directories on the way to the File, and 'read' permission on the File itself.
For example, in order to read the File "/etc/passwd", the User must have all of the following permissions:
- 'x' permission on Directory "/"
- 'x' permission on Directory "/etc"
- 'r' permission on the File "/etc/passwd" itself

Access Permission scenarios

Let's see how, using combinations of File and Directory permissions, we achieve the following scenarios:
- Create a File, in our home Directory, with 'read' access to everyone.
- Put a program File under Directory "bin" in our home Directory, with permission to be executed by everyone.
- Create a File with 'read' access to a selected Group of Users.
- Create a File with 'read' access to everyone, except a selected Group of Users.

'read' Permission To Everyone On A File

Create a File with 'read' access to everyone, in our home Directory:
- Create the File in the home Directory.
- Give 'read' access to "User-owner", "Group-owner", and "Others":
  
  chmod a+r <file_name>
  
  (Note: 'a' is a short-hand for "all" - i.e. "User-owner", "Group-owner" and "Others")
- Give 'x' access to our home Directory, so the Users will be able to reach for Files in it:
  
  chmod a+x ~
  
  (Note: '~' is a short-hand for our home Directory)

'execute' Permission To Everyone On A File in ~/bin

Create a File with 'execute' access to everyone, in Directory "bin" under our home Directory:
- Put the program File in the Directory "bin" under our home Directory.
- Give 'execute' access to "User-owner", "Group-owner", and "Others":
  
  chmod a+x <file_name>
- Give 'x' access to our home Directory, so the Users will be able to reach for the "bin" Directory under it:
  
  chmod a+x ~
- Give 'x' access to our "bin" Directory, so the Users will be able to reach for the program File located in it:
  
  chmod a+x ~/bin

'read' Permission To A Selected Group Of Users, On A File

Create a File with 'read' access to a selected Group of Users:
- Ask the system administrator to create a new Group containing this list of Users.
  
  Note: We must be part of the Group, in order to be allowed to turn it into the Group-owner of the File.
- Make the new Group be the Group-owner of the File:
  
  chgrp <group_name> <file_name>
- Give 'read' access to "Group-owner":
  
  chmod g+r <file_name>
- make sure "others" don't have 'read' access to this File:
  
  chmod o-r <file_name>
- Give 'x' access to our home Directory, so the Users will be able to reach for the File under it:
  
  chmod a+x ~
- Note: if the File is in a sub-Directory under our home Directory, we must give 'x' access to all the Directories along the way to this File.

'read' Permission To Everyone except a Group of Users

Create a File with 'read' access to everyone, except a selected Group of Users:
- Create a new Group, containing the list of 'forbidden' Users.
- Make the Group-owner of the File be this Group.
- Give 'read' permission on the File to "others", but deny this permission from the Group-owner.

Users and Processes

Every process running on a Linux system, executes on behalf of a given User.
Thus, the process may do what this User is allowed to do.
The process may access the Files that its User-owner may access...
...Except when it can access other Files, as we will see later.
Every process has unique process ID (= pid), which can be used to control the process, as we will see soon.

Listing The Running Processes

The ps command is used to view a list of running processes. When running it with no parameters, we get something like this:

     [choo@simey ~]$ ps
       PID TTY          TIME CMD
      1235 pts/3    00:00:00 tcsh
      2014 pts/3    00:00:00 ps

The output is divided into the following columns:
- PID - the process ID.
- TTY - the "terminal" under which the process is running ('?' if none).
- TIME - the CPU-time this process consumed so far (hours, minutes, seconds).
- CMD - the command this process is executing.

Listing The Running Processes - Wider Format

In order to see more details about the processes, we should run the ps command with the u flag:

     [choo@simey ~]$ ps u
     USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
     choo      1235  0.0  0.5  2856 1444 pts/3    S    14:42   0:00 -csh
     choo      2061  0.0  0.3  2624  776 pts/3    R    18:43   0:00 ps u

The output is divided into the following columns:
- USER - the User this process runs on behalf of.
- PID - the process ID.
- %CPU - percent of CPU time this process used.
- %MEM - percent of memory (physical RAM) this process uses.
- VSZ - amount of virtual memory this process uses.
- RSS - amount of physical memory this process uses.
- TTY - the "terminal" under which the process is running ('?' if none).
- STAT - the status of the process:
  - S - Sleeping.
  - R - Running (at most one per CPU).
  - D - uninterruptible sleep (BAD if a process is in this state for too long). The process cannot be killed or stopped in this state.
  - T - traced or stopped process.
  - Z - Zombie (in the state of exiting).
- TIME - the CPU-time this process consumed so far (hours, minutes, seconds).
- CMD - the command this process is executing.

Listing The Running Processes - Variations

In order to list all processes we are running under our current shell:

ps
In order to list all processes we are currently running:

ps x
Listing all processes running on behalf of a given User:

ps -u <user_name>
Listing all processes running on the system:

ps ax
Listing a processes with a given pid (= process ID):

ps -p <pid>

Controlling Processes

A User may only control processes running on behalf of this User...
...Except when the User is "root" - which can control any process running on the system...
...Assuming this process is not stuck in a very "stuck" state.
In order kill a process with a given pid (=process ID):

kill <pid>
In order kill a "stubborn" process (when a normal kill fails to kill it):

kill -9 <pid>
In order to temporarily suspend a given process:

kill -STOP <pid>
In order to resume a suspended process:

kill -CONT <pid>

Processes And Files

A Process, as we saw before, can open a File.
The Process may open the File for reading, writing or both.
When a Process is done working with a File, it usually closes the File.
When a Process terminates, the operating system makes sure all Files it held open, are closed.
When a File is held open by a Process, and we delete the File, the File is only removed from the Directory, but is NOT yet deleted from the disk. Only when the Process closes the File, will the File be actually deleted from disk.

Which Processes Hold A File Open? (fuser)

In order to see which Processes currently hold a File open, we can use the fuser command:

     [choo@simey ~/haifux]$ /sbin/fuser .
     .:                    1262c
     [choo@simey ~/haifux]$ ps -p 1262
       PID TTY          TIME CMD
      1262 pts/2    00:00:00 tcsh

The fuser command shows a list of Process-ID-s currently holding a given File (or Directory) open.

Which Processes Hold A File Open? (fuser, Cont.)

Note that the fuser command is usually located in the "/sbin" Directory - which is not found in the User's PATH, so we needed to invoke it as /sbin/fuser.
The flag that
fuser attaches to a Process-ID is one of:
- c - current Directory.
- e - executable being run.
- f - open File. f is omitted in default display mode.
- r - root Directory.
- m - mmap'ed File or shared library.

Which Files Are Open By A Given Process? (lsof)

For the reverse question, which Files are currently open by a given process, we use the lsof command:

[choo@simey ~/haifux]$ /usr/sbin/lsof -p 1262
COMMAND  PID USER   FD   TYPE DEVICE    SIZE   NODE NAME
tcsh    1262 choo  cwd    DIR    3,6    4096 633934 /prog/choo/haifux
tcsh    1262 choo  rtd    DIR    3,1    1024      2 /
tcsh    1262 choo  txt    REG    3,1  288604  16273 /bin/tcsh
tcsh    1262 choo  mem    REG    3,1   85420  20367 /lib/ld-2.2.5.so
tcsh    1262 choo  mem    REG    3,3      57  33037
                      /usr/lib/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES
tcsh    1262 choo  mem    REG    3,3     370  51080
                      /usr/lib/locale/en_US/LC_IDENTIFICATION
tcsh    1262 choo  mem    REG    3,3      28  52557
                      /usr/lib/locale/en_US/LC_MEASUREMENT
tcsh    1262 choo  mem    REG    3,3      64 112345
                      /usr/lib/locale/en_US/LC_TELEPHONE
tcsh    1262 choo  mem    REG    3,3     160 112347
                      /usr/lib/locale/en_US/LC_ADDRESS
tcsh    1262 choo  mem    REG    3,3      82 112346
                      /usr/lib/locale/en_US/LC_NAME
tcsh    1262 choo  mem    REG    3,3      39  52571
                      /usr/lib/locale/en_US/LC_PAPER
tcsh    1262 choo  mem    REG    3,3     291  52556
                      /usr/lib/locale/en_US/LC_MONETARY
tcsh    1262 choo  mem    REG    3,3   21499  83114
                      /usr/lib/locale/en_US/LC_COLLATE
tcsh    1262 choo  mem    REG    3,3    2456  51083
                      /usr/lib/locale/en_US/LC_TIME
tcsh    1262 choo  mem    REG    3,3      59 112348
                      /usr/lib/locale/en_US/LC_NUMERIC
tcsh    1262 choo  mem    REG    3,1   85262  20377 /lib/libnsl-2.2.5.so
tcsh    1262 choo  mem    REG    3,1   11832  20340 /lib/libtermcap.so.2.0.8
tcsh    1262 choo  mem    REG    3,1   22645  20374 /lib/libcrypt-2.2.5.so
tcsh    1262 choo  mem    REG    3,1 1343176  20372 /lib/libc-2.2.5.so
tcsh    1262 choo  mem    REG    3,3  173764  98443
                      /usr/lib/locale/he_IL/LC_CTYPE
tcsh    1262 choo   15u   CHR  136,2              4 /dev/pts/2
tcsh    1262 choo   16u   CHR  136,2              4 /dev/pts/2
tcsh    1262 choo   17u   CHR  136,2              4 /dev/pts/2
tcsh    1262 choo   18u   CHR  136,2              4 /dev/pts/2
tcsh    1262 choo   19u   CHR  136,2              4 /dev/pts/2

Which Files Are Open By A Given Process? (lsof, Cont.)

Note that the lsof command is usually located in the "/usr/sbin" Directory - which is not found in the User's PATH, so we needed to invoke it as /usr/sbin/fuser.
Types of Files held open by processes:
- cwd - Current Working Directory.
- rtd - Root Directory.
- txt - Binary File (the program that this Process executes).
- mem - Memory-Mapped Files - often libraries used by the program.
- 0 - The File/terminal from which the process reads "user" input.
- 1 - The File/terminal into which the process writes "user" output.
- 2 - The File/terminal into which the process writes error messages.
- <number> - A regular File.

Default Permissions For New Files

By default, when we create a File , it is automatically given permissions 'rw' for everyone.
For a new Directory, it is given permissions 'rwx' for everyone.
Controlling the default permissions given for new Files or Directories, is done using the umask command.

The umask Command

The umask command tells which permissions should NOT be given to newly created Files.
The umask command takes one parameter, which is a number in octal, such as:
```
     umask 022
     
```
The above command states that for new Files, we should NOT give the 'w' permission to "group" and "others". Why? see the next slides...

The Octal Notation Of Access Permissions

Access permissions for Files can be stated using an octal number with 3 digits.
The first digit denotes the permissions for the User-owner.
The second digit denotes the permissions for the Group-owner.
The third digit denotes the permissions for "others".

The Octal Notation Of Access Permissions (Cont.)

Each digit is made of 3 binary bits, representing 3 permissions, 'r', 'w' and 'x'.
Each digit represents 3 permissions, 'r', 'w' and 'x'.
Thus, '1' represents 'x', '2' represents 'w', and '4' represents 'r'.

The following table shows the translation of values to permissions:

Value	'r'	'w'	'x'
0	-	-	-
1	-	-	+
2	-	+	-
3	-	+	+
4	+	-	-
5	+	-	+
6	+	+	-
7	+	+	+

The Octal Notation And umask

When we create a new File, the operating system first takes the default permissions ('rw-rw-rw-', or 0666 in octal).
Then, every bit that is set in the umask, is being cleared in the permissions.
The resulting number is set as the permissions given to the File.
This sounds complicated - but after a while you get used to it.
Eventually, we set a umask in our shell's start-up script, write a comment explaining what it does, and then forget about it.

Special Access Permission Flags

Other than the normal permission flags, each File has several other special flags, with strange meanings.
Because some of these permission flags give rather "strong" results, they should be used with caution.
However, we should not be tempted to delete permissions that look redundant without fully understanding why they are set that way - such changes could break the entire system.

The "Set User-ID" Flag

The "suid" (Set User-ID) flag, is mostly meaningful when set for a File containing an executable program.
When set, it means that when a User runs this File, the launched process will have the permissions of the User-owner of the File, rather than the permissions of the User running the program.
This flag is often used in order to temporarily give Users access to Files they cannot normally access.
For example, the X server is often installed with the "suid" flag set, in order to allow the User to access the graphics devices (screen, keyboard, mouse):
```
[choo@simey ~]$ ls -l /usr/X11R6/bin/XFree86
-rws--x--x    1 root    root     1602576 Apr 19  2002 /usr/X11R6/bin/XFree86
     
```
(note the 's' in the User-owner permission bits).

The "Set Group-ID" Flag

The "sgid" (Set Group-ID) flag, is mostly meaningful when set for a File containing an executable program, or for a Directory.
When set for a File, it means that when a User runs this File, the launched process will have the permissions of the Group-owner of the File, rather than the permissions of the default-Group of the User running the program.
When set for a Directory, it means that new Files created in this Directory, will belong to the Group-owner of this Directory, rather then to the default-Group of the User creating them.

The "Sticky" Flag

The "sticky" flag, is mostly meaningful when set for a File containing an executable program, or for a Directory.
When set for a File, it means that the File should be copied into the swap device, rather than loaded from its original location. This could make the File load faster.
When set for a Directory, it means that users cannot rename or delete Files in this Directory, unless they own these Files.
This flag is normally set for Directory all users can create Files in, such as "/tmp" or "/var/spool/mail".

Symbolic Links

Linux allows creating a File, which is actually a link to another File (or Directory).
Such a File is called "symbolic link".
Symbolic links can be used for:
- Creating a short-cut for a File with a long path.
- Giving a program the impression that it can find a File in one location, even if the File is found in a different location.
- Amazing your friends or bewildering them.

A Symbolic Link Example

For example, look at the following output, which is a detective-work of finding the real program that is the mail server on my system (note: long lines were broken down, so they can fit the screen):

[choo@simey ~]$ ls -l /usr/sbin/sendmail
lrwxrwxrwx    1 root     root           21 Aug 15  2002
                         /usr/sbin/sendmail -> /etc/alternatives/mta
[choo@simey ~]$ ls -l /etc/alternatives/mta
lrwxrwxrwx    1 root     root           27 Aug 15  2002
                         /etc/alternatives/mta -> /usr/sbin/sendmail.sendmail
[choo@simey ~]$ ls -l /usr/sbin/sendmail.sendmail
-r-sr-xr-x    1 root     root       451280 Apr  8  2002
                         /usr/sbin/sendmail.sendmail

The symbolic link has an 'l' as the File type (first character in the output of "ls -l").
The symbolic link has permissions of 'rwxrwxrwx'.

Symbolic Links Semantics

When "reading" a symbolic link, we actually read the contents of the actual File the link points to.
When there is a symbolic link to a Directory, and we cd into it, we actually switch into the Directory the link points to.
If we then cd .., we switch into the Directory containing the linked Directory, rather than into the Directory containing the symbolic link.

Permissions And Symbolic Links

In order to access a File via a symbolic link, we need to have access permissions on the final File itself, not just on the link.
To see the attributes (permissions, last modification date) of the actual File that a symbolic link points to, we can avoid being detectives, and use the -L flag:
```
[choo@simey ~]$ ls -lL /usr/sbin/sendmail
-r-sr-xr-x    1 root     root       451280 Apr  8  2002 /usr/sbin/sendmail
     
```

What We Did NOT Cover Today

Device Files - will be discussed during the next lecture (installing device drivers).
Hard Links - when a File has more than one name.
Communications Files - sockets, named pipes.

Google for them all on your spare time...

Originally written by

guy keren