sections in this module City College of San Francisco - CS260A
Unix/Linux System Administration

Module: Virtual Machines
module list

Privileges - Introduction

All operations performed on a Unix system can be divided into two groups: operations that request operating system services, and operations that affect data. We are all aware that many of these operations are illegal for us. In this section we will examine the different ways we can be granted a full or partial reprieve of these restrictions.

When you log into a Unix system as a normal user, you assume the identity of the login user. By default, every process you execute, and every operation you attempt, executes as that user. The user's id, and the groups it is a member of, determine your rights on the system.

The most familiar restriction to most users on a Unix system governs data. This restriction is imposed by permissions. Every piece of data on the system has certain permissions. Your permission to operate on that data is determined by how the permissions of the data match who you are. If you are able to log in as a different user, your access rights change. Many users that have more than one login have experienced this.

In addition to restrictions imposed by data permissions, many operations on the system are privileged. That means that normal users cannot perform those operations. 

A single user on a Unix system is immune to these permissions restrictions and is allowed to perform privileged operations. This the user with user id 0, commonly called root. The 'root user' is often lovingly referred to as 'the superuser'. The system may impose some restrictions on operations by root from time to time. However, these restrictions are configurable. Since root is able to modify any configuration, it can always escape the restrictions.

In this module, we will learn about the various ways of gaining privileges on a Unix or linux system. We will begin with the most obvious and dangerous of them all: assuming the identity of root for an entire shell session. We will also discuss the user of set-user-id programs to allow other users to run a program as root.

Modifying Configuration Files

From time to time you will have to modify system configuration files. It is important to get in the habit immediately of doing this in a controlled manner.

  1. select a naming scheme to keep a copy of the original file before the modification. This is up to you. Common systems are adding an extension such as .orig or .sv or .installed. A more arcane older system is to append a dash to the end of the original name. Whatever you choose, be consistent!
  2. before modifying anything, make your copy to preserve the original. Make sure, of course, that you haven't designated an original previously! In that case you must resort to the diff program, which we will discuss shortly
  3. once your backup copy is made, modify the file
  4. if you want to revert to the original, move (mv) it back so that it does not appear modifications have been made.

One issue with modifying configuration files is that updates to the package containing the configuration file may result in overwriting it. In this case, the update process will often generate a message that indicates the modified file was saved, or it may not. Here you are responsible for verifying that your changes were preserved.

The conflict between updating configuration files during a release and local user modification of them has been resolved in many packages by the implementation of a configuration directory. Here, the main configuration file includes all the files in a configuration directory. The purpose of the configuration directory is to allow local modifications (in the form of a file in the configuration directory) to be included at the end of the main configuration file. This way future releases may change the main configuration file, and the local modifications will still be applied.

You should always look for a configuration directory before modifying the main configuration file. If one exists, place your updates there rather than in the main configuration file. The configuration directory is usually very similarly to the configuration file, with the suffix .d

An example of a configuration directory is the main profile file /etc/profile. This file is often modified during system updates, and it includes each file in the directory /etc/profile.d The profile.d directory contains many system-supplied additions to the profile, and the administrator can drop additional modification files in it as well. In this case, the files in profile.d are shell code that is sourced (using the dot operator) from the main /etc/profile script.


Prev This page was made entirely with free software on linux: 
the Mozilla Project, Kompozer and Openoffice.org    
Next

Copyright 2013 Greg Boyd - All Rights Reserved.