Linux is today considered the most secure operating system by many. One of key factors to system security is access permission control. All modern operating systems support this feature, which I believe first appeared in UNIX operating system. It allows file owners to restrict who can read, write, execute and otherwise change files, running processes ('tasks') and other parts of the system.
Linux, as every UNIX-like OS, has a built-in file permission control system. It assigns the following attributes to every file on its file system:
- Owner - user who owns the file, has unlimited control over it and can change other file attributes.
- Group - user group that the file belongs to.
- UNIX permissions - a set of rules defining who can do what to the file. Fear not, it is discussed below.
Code: Select all
id -a
Used terms:
file system - an on-disk structure holding descriptions of files (such as the attributes mentioned above, file modification date etc.) and the files' contents themselves. File systems are contained in disk partitions (also called slices). Most popular file systems today are ext3, xfs and reiserfs. If you run Debian, you probably use ext3.
Worth mentioning is the fact that directories ('folders') are also considered files, simply containing other files. Therefore, permissions apply to directories, too.
user group - in UNIX-like systems, every user is assigned to some group. Users in the same group may share rights, for example a file's permissions may be set so that all users in a group can modify its contents.
Section 2: UNIX permissions explained
Having learnt the theory, it's time to pass on to practice - what do UNIX file permissions look like and how to use them?
First of all, let us examine the permissions of an example file. By issuing the following command in Linux console or a terminal emulator:
Code: Select all
stat /etc/hostname
Code: Select all
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access field contains an octal number and its human-readable representation (I personally consider the numeric one to be more readable). It is crucial to know what the permission number means.
It consists of four digits, ranging from 0 to 7. For now, we shall skip the first one and focus on the last three, as they are used most commonly on every system. In our example, those are 644.
Each digit may be a sum of 4, 2 and 1, but not every component has to be included, giving a possible range from 0 to 7. Below is the meaning of the sum components, with Subject being user, group or others, as discussed below.
- 4 - read permission. Subject is allowed to read the contents of the file.
- 2 - write permission. Subject may modify file contents, move the file or delete it. With directories, it allows the subject to list its contents in conjunction with 1.
- 1 - execute permission. Subject may execute the file, provided that it is a program or a script. In case of directories, execute permission lets the subject traverse through directory into subdirectories. See the note on path handling below.
The digits define respectively: owner, group and others' permissions. Therefore, we can see that, in our example, file owner (root) may write to the file and read its contents, while group 'root' and other users (not being root nor a member of group 'root') are given the right to read the file.
Now, compare it to file permissions of /etc/shadow (use 'stat' again). This file has 0 as the third meaningful digit, so users not being root nor in group 'shadow' may not even read the file. You can easily confirm that by running a text editor and trying to open /etc/shadow - you, as a regular user, should not be allowed to see its contents as it contains system-wide passwords (and this is beyond the scope of this little How To).
A note on path handling
To access any path in the filesystem, the user (which the particular process is running as) needs at least execute privilege for all its parent directories. Therefore, if you try to access an example file /etc/security/limits.conf, even though it has a mode of 0755 (for the sake of example), it does not necessarily mean you are free to read it. To read the file, you have to be able to 'execute' all of its parent directories, so you need execute permission on /etc and /etc/security. If either /etc or /etc/security has permissions set so that you are not allowed to execute it (1), then reading /etc/security/limits.conf will fail. This rule applies anywhere in the filesystem.
Section 3: Modifying file permissions
This section shows, using an example, the very basic usage of chmod command. Chmod is one of sysadmin's best friends and the standard tool for manipulating file permissions in various Unices (also works with *BSD and Solaris!). Let's begin...
First of all, create a file for demonstration purposes. In the example, I will be using name testfile. Commands below are to be executed in a terminal emulator or Linux console. You can basically just copy, paste, and see how it works.
Code: Select all
# first of all, create the file using touch command (see 'man touch' for details)
touch testfile
# now, let's see its permissions
stat testfile
# modify the file so that group members and other users can write to it
chmod 666 testfile
# see the new permissions
stat testfile
If you only have one user account, create a new one for testing:
Code: Select all
su
(your root password here, to log on to root account and add a test user)
adduser demo
# you can remove this user when you've finished: deluser demo
You may now want to check it with various different permissions. Try chmod with arguments like 644, 640 and so on.
To be continued in part 2