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

• Historycally, 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 - uninterruptable 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>

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.

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.
  • Amaze your friends or bewilder 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 usually has permissions of 'rwxrwxrwx' - but this is not necessary.

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 two files are actually the same file.
• Communications Files - sockets, named pipes.

Google for them all on your spare time...

Originally written by guy keren