Permissions I

Summary:

• The Concept
• Why Understanding Permissions Is Important

The Concept

Linux knows users by their accounts. In order to use your system, you have to tell it who you are (i.e. which account you want access to) by 'logging in'. Having done that you will be taken to your account's home directory ('/home/account'), where you can do pretty much what you want.

Each UNIX system has one 'human' account already built-in, and that's the 'root' account. The 'root' account is special in several ways: its home directory is '/root' and whoever is 'root' has total control over the system.

The basic idea behind this scheme is to allow separating the daily use of an operating system from system administration. Among other things this prevents an error made during normal use of the operating system to have any severe impact on the operating system itself.
It also allows for different users on the same system. These additional users do not have to be human: system services often have accounts of their own, so that they don't have to be run via the 'root' account. This way a mis-configured system service is prevented from having a major impact on the operating system itself, too.

Now, how does the operating system determines who is allowed to do what? This is where permissions kick in.

Each file on a UNIX system has a permission setting, represented by the first ten characters in a file listing and the ownership names:

ls -l file
-rw-rw-r–– (...) owner group (...) file

Everything in UNIX is managed via files, even access to devices (via the device files in '/dev') like printers, modems, sound cards etc. If you do not have the permission on a file which represents a device, you can't use that device.

The first concept of permissions is ownership. You either own a file or a directory you have created or that has been handed over to you by using the 'chown' command (short for 'change owner', more on this command later). If you own a file, you can do whatever you want with it, usually.

But often more than one account needs access to a file or device. Changing the ownership of this file every time someone else needs access to it would be very tedious to say the least. This is why ownership is not only provided for single accounts but also for groups. Groups are defined in '/etc/group', an entry in this file looks like this:

group_name:x:group_ID:group_members

To see a list of groups your current account is a member of, use the command

groups

So, if you are member of a group and that group has permissions on a file, you can do something with that file, even if you are not its owner.

An average UNIX system has some 60.000 files and more. A majority of them has to to accessible in some way by all the users on a system. One way to achieve this could be to create an 'catch-all' group which would unite all the accounts on a system and assign all the files in question to this group. But since permissions do not only decide who has access to a file, but also what kind of access, such a group would defeat the purpose of the system: there are many cases in which members of a certain group need more rights on a file, but others need limited access to this file, too. This is the rationale behind the others 'group'. Permissions on a file given to this particular group are granted for all accounts on a system. Have a look at the example again:

ls -l file
-rw-rw-r–– (...) owner group (...) file

Characters 2-4 ('rw-') describe the permissions of the owner, characters 5-7 ('rw-') describe the permissions of the owner group, and characters 8-10 describe the permissions of everyone else on that file.

Let's move on from the 'who' part of permissions to the 'what' part. There's pretty much you can do with (or to) a file: you can read it, change it, delete it or - in some cases - execute it. Permissions decide which of these actions can be taken, too. This is the concept of accessibility.

Permissions on access can be granted in three ways: permission to read (marked with 'r'), permission to write and delete (marked with 'w') and permission to execute (marked with 'x'). In the above example the owner and the owner group have the permissions to read and change / delete the file. Everyone else might read the file, but is not allowed to change its contents.
No one may execute this file. In contrast to operating systems like Windows 9x, a file must not only contain executable content (either binary or script) but it must also have the execution bit set. This allows to exclude accounts from running the file or program, usually for system security reasons. Even 'root' can't execute files without the execution bit, but he or she can make every file executable. Of course, if this file doesn't contain executable content, you still won't be able to execute it, regardless of the execution bit.

Directories also feature permissions. Due to their nature, the permission bits have a slightly different meaning: 'r-x' means being able to list directory contents and to make this directory the working directory. 'rwx' means being allowed to put into or remove files from that directory. Every other combination of permissions will not allow you to access this directory.

(Notice that with the introduction of the Mandrake Security Tools (MSEC) in ML 7, default permissions on files may differ widely depending on the overall security level chosen during installation or later using '~DrakConf'.)

section index

Why Understanding Permissions Is Important

It is a distinguishing mark of the Unix/Linux concept of computing to manage all input/output operations via files. If you send a file to your printer for example, you in fact send it to the file '/dev/lp0'. If you are connected to net via a modem all data is written and read from '/dev/ttyS0' (or S1/S2/S3).
The upshot is that either you or the program you execute need permission to read and write that file. Without this, it won't work. The same applies to directories: you can't run a program which resides in a directory you don't have access to or which needs write access to a directory you don't have write access to. Many configuration problems are simply due to wrong permissions. Checking permissions is an important step in troubleshooting.

Now you might say that since you are the only user on your machine, 'why fiddling around with all this permissions stuff, I just stay root, so I am allowed to do everything'.
This is precisely the reason why you shouldn't do that. A single wrong root command can blow your system to pieces, whereas as a simple user you just can't break anything vitally important. Especially if you are new to Linux you really should use this mechanism to protect yourself from your errors.
But there is even more to that:
Most programs you start run with the permissions of the user that started them. So if you started a program as a normal user and it runs berserk you can normally kill it easily and it can't do any real damage because it has no rights to do so. Now imagine the same with a program with root privileges… I think you see the point.

The execute permission on a file indeed makes this file executable. Many files of script languages like Perl or even simple shell scripts rely on this. If you've downloaded a script and it just won't run, check if the execution bit has been set (see next chapter).

Programs can run with a different user id (UID). Some programs require root privileges even if they are started by a normal user (like the X server via the Xwrapper in '/usr/X11R6/bin'), such programs are indicated by an 's':

-rws––x––x 1 root root {...} /usr/X11R6/bin/Xwrapper*

(the asterisk sign '*' tells you that it is an executable file).

However such programs pose a security threat since they allow crackers to gain root access to a box using so-called overflow exploits. Therefore it is advisable to keep the number of such programs as small as possible and have an eye on security alerts. Notice that Linux won't execute SUID shell scripts.

section index

Confusing, isn't it? ;-) Have a look at some practical examples ...

Related Resources:

man chmod
man chown
LIGS, 3.1

Revision / Modified: April 21, 2002
Author: Tom Berger

Legal: This page is covered by the GNU Free Documentation License . Standard disclaimers of warranty apply. Copyright LSTB and Mandrakesoft.