The Linux system distinguishes users. The extent to which they may influence each other and the system itself is clearly defined. File permissions are structured in such a way that a regular user cannot delete or alter files in /bin or /usr/bin directories, for instance. Most users protect their files by setting the appropriate access rights in such a way that other users either do not have access to them or cannot alter or delete them. In fact, no one wants to make his or her electronic mail messages accessible to other users. Every user registered in the system has an account name, which is also a name of his/her home directory. Aside from this, the system creates special user names with extraordinary privileges. The user root, which is usually used by a system administrator, is the most important one. In most cases, no distinction is made between the concepts of the root user and the person acting as a system administrator.

There are no limitations to what the root user can do. He or she can read, alter or delete any file in the system, alter access rights and ownership of any file, run any special programs. For instance, those that create partitions or filesystems in a hard drive. The main idea is that the person who is responsible for the integrity and workability of the operating system logs into the system as the root user and performs actions that cannot be done by a regular user. Due to the fact that the root user is allowed to do everything, his or her mistake can lead to disastrous results.

If a regular user tries to delete all files in the /etc directory by mistake, the system will not allow this. But if the root user tries to do the same, the system will do what is requested without even issuing a warning. Thus, if you are working as the root user, it is extremely easy to destroy the operating system. The best way to prevent such consequences is the following:

Work in the system with root privileges should be seen as temporary possession of some kind of a magic wand that gives great power, but this power may also lead to great destruction. It is very important to pay close attention to which exact keys your fingertips are pressing at those moments. Although holding the magic wand gives unique sensations, it is advisable to try not to grab it too often.

Any kind of everyday work in Linux that is not system administration can be, and should be, done by unprivileged users. This rule should be followed, so that the likelihood of making the system inoperable (by an accidental mistake or by possible errors in programs used by you) is minimized.

Unfortunately, a large percentage of software code is ignorant from the security viewpoint. By running such programs as an unprivileged user, you are automatically diminishing the risk of damaging the system by a failure, and making it more difficult for potential intruders to interfere with your system.

Administrative tasks require the root user privileges. It should be noted that the root account settings are determined by the specifics of the common system administration tasks, and thus they are not intended for everyday work and are localized into other languages only to a limited degree.

sudo is a program that is developed to help a system administrator and allows to delegate certain “privileged” resources to users, while keeping a logfile of events. The basic idea is to give users as few privileges as possible, but enough to accomplish the required tasks.

The sudo command gives users an opportunity to execute commands under root privileges, or under privileges of other user accounts. The rules used by sudo to decide whether access should be given to specific users are written in /etc/sudoers file. The language in which they are written, with examples of their use, is described in detail in the sudoers(5) manpage. Besides, an example of a set of rules allowing unprivileged users to install, update and remove packages in the system ^[1] is given in the file /usr/share/doc/sudo-<version>/rpm.sudoers.

To edit the file /etc/sudoers, you should use the program visudo, which checks its syntax and thus helps to avoid errors in rules.

In most cases, valid configuration of sudo makes it completely unnecessary to work as a superuser (root user).

It is very important for a person responsible for the operability of the system to have a clear concept of what exactly is going on in it. Theoretically, no event should be able to elude his or her attention. But computer systems are so complicated that they exceed human capabilities to monitor all events in them. Instead, to make the volume of service information flow reasonable, it should be filtered (i.e., insignificant data should be thrown out), classified (separated into several groups according to topic) and logged (stored in an accessible form for subsequent analysis).

In Linux this task is solved using the centralized logging mechanism, implemented by the syslogd daemon (system service). All parts of the system (including the kernel and system services) report to syslogd about events that take place in them. The resulting report includes the service name, facility (category) and level of priority of the event that took place. The daemon will classify all these reports into several output streams according to the settings. Classification and filtering of any output channel are done in the following way: for each event category the priority is set to the lowest priority value that an event may have to be able to get into this output stream. For example, it is easy to define the “errors” stream, which will receive only the important reports belonging to any category, or the “security” stream, which will receive all the reports in the “security” category, and those reports in other categories, the importance of which makes one suspect a threat to the system security (for instance, a report from the “daemon” category about an emergency shutdown of a system service).

The main storage location for an event stream already classified by syslogd is the system journal (or the system log file). The system log file is a text file that contains reports from one stream. Usually, syslogd stores system logs in /var/log directory and its subdirectories. System logs, particularly /var/log/messages, /var/log/maillog and /var/log/dmesg, are the primary source of information for an administrator who wants to know what is happening in the system. A stream of reports about important events is also directed by syslogd to the system console, a dedicated terminal device. In ALT Linux, the role of the system console is played by the 12th virtual console, accessible by pressing Alt-F12 or Alt-Ctrl-F12 key combinations. It should be noted that some services (for instance, the Apache WWW server) keep logs of their events independently of syslogd, and so the information about the number and location of their log files can be obtained from their configuration files (however, log files are usually stored in /var/log).

New reports that enter the system journal are the most important and up-to-date, whereas the prior ones gradually lose their importance as they get older. If the least recent reports in the journal are not deleted, the filesystem will sooner or later become full. In Linux, a mechanism of log expiration is organized, handled by the logrotate service. Launched once a day, logrotate checks which of the files should now be considered expired. A file is declared obsolete once in a certain time period (for instance, once a week), or once it reaches a certain size.

The expiration procedure is as follows. For each journal, such as, for example /var/log/syslog/alert, logrotate keeps a queue of obsolete copies, i.e. files with names that start with alert.0.bz2 (previous copy) and end with alert.4.bz2 (the oldest copy). The alert queue in our example consists of five files packed using bzip2. When alert.3.bz2 becomes obsolete, it is renamed into alert.4.bz2 (old data in alert.4.bz2 is lost), a copy with number 2 is renamed into number 3, number 1 becomes number 2 and 0 becomes 1. Finally, the journal itself is packed and renamed into alert.0.bz2, and another empty one is created in its place. Thus, an administrator always has access to a fresh journal and to several older ones stored for a certain time period.

Some files in /var/log directory are non-text files: they are a kind of “event dumps” for authorization and registration services, rather than fully functional log files. Text information about users logging in and out of the system may be obtained by issuing the command last. To find out who is using the system at this very moment, commands w and who will help.

A system workload analysis in terms of processor time and random-access memory consumption may yield a lot of useful information. This is accomplished by issuing the commands ps, top, or vmstat. The commands du, df and lsof are used to analyze the usage of disk space. The command netstat provides information about the functioning of network devices.