Practical Examples

Confused? :) Well, maybe things will get somewhat clearer with real life examples.

Files

A very good example is the 'slocate' package. If you've got that package installed, open a terminal and type:

ls -l /usr/bin/updatedb

That's the program for updating the '(s)locate' database. You should get something like:

-rwxr-xr-x 1 root slocate [...] /usr/bin/updatedb*

The first nine characters describe the access rights (the first '-' denotes the file type):

Owner | Group | Others = rwx | r-x | r-x

Remember: 'r' stands for 'read', 'w' for write, and 'x' for execute. '-' means 'not set' and therefore no right. The order of rights is always 'rwx'. So this string decodes to:

• file can be read / written to - or deleted - and executed (rwx) by its user (owner).
• file can be read only and executed (r-x) by members of the owner group.
• file can be read only and executed (r-x) by everyone else.

Now you need to know who is the user (owner) of this file and to which group it belongs to. You'll find this information right after the inode number (1):

root slocate

Owner is root, name of the group is 'slocate'.

Directories

Too easy so far? Right so. If you try to execute this program as a normal user, you get:

slocate: You are not authorized to create a default slocate database!

The slocate database is in '/var/lib/slocate'. Let's have a look:

ls -l /var/lib/
drwxr-x--- 2 root slocate [...] slocate/

The rights on this directory look somewhat different:

• The owner ('root' here) has the right to enter this directory (rx) and to add to or delete its content (w)
• Members of the group 'slocate' may enter this directory and read its content (rx)
• Others have no rights at all (---).

(Remember: In regard to directories the read and execute permission belong together, i.e. you must have both rights to be allowed to enter a directory!).
Since you are not 'root', you can't run 'updatedb': you lack the right to change content in '/var/lib/slocate'.
Now you might wonder: "If I don't have access to the slocate database, how comes I can run 'locate' as a normal user? It surely needs access to this database as well!" That's correct.

setUID, setGID

If you run ls -l /usr/bin/locate, you will get something like this:

-rwxr-sr-x 1 root slocate [...] /usr/bin/locate*

Note the 's' that replaces the 'x' in the column of the group rights. This denotes another important mechanism you might have already heard of earlier: the setUID/setGID mechanism. This mechanism allows users to execute a program with a different User or Group ID.
Every account and group has an associated unique ID number, since the operating system prefers dealing with numbers instead of names. You use names and the system translates that into numbers. You don't have to worry about those, I just mention them here to explain where 'setUID' and 'setGID' come from. If you are really curious, run

id

But if you run 'locate' the 'setGID' ('set Group ID') bit on the 'slocate' executable makes the system think you are a member of the group 'slocate' and thus grants you read access to the database in '/var/lib/slocate'.
The same happens with programs which run 'setUID' ('set User ID'), usually 'setuid root', like the aforementioned 'Xwrapper':

-rws--x--x 1 root root [...] /usr/X11R6/bin/Xwrapper*

The 'Xwrapper' tricks the operating system into thinking that you are 'root' when you start X. The advantage here is that this program allows you to run X and applications on X without having to be root (see Introducing Processes).

section index top

Changing Permissions

Remember: Permissions encompass two concepts, ownership and accessibility. Therefore you have two ways of influencing permissions: changing the ownership with the command 'chown' (CHange OWNer) or changing the accessibility with the command 'chmod' (CHange MODus).

Changing Ownership With 'chown'

'chown' is a fairly simple command:

chown tom:users test.txt

changes the ownership of the file 'test.txt' to owner 'tom' and group 'users'. You can only 'chown' files which you are owning (only 'root' can 'chown' files and directories which are not owned by him). If you just want to change the owner group, use 'chgrp'. You can do this 'recursively' (i.e. for every subdirectory and the files contained therein) by appending the '-R' option:

chown -R tom:users docs

sets the ownership of all files and directories in the directory 'docs' to owner tom, group users.

Changing Accessibility With 'chmod'

'chmod' is somewhat more difficult to handle. There are three groups: user, groups and others. Take the first letters: u, g, o. And there are three rights: read, write, execute (rwx). 'chmod's syntax goes like this (simplified):

chmod [ugo] [+-] [rwx] file

Let's say you want to grant (+) the 'read' right (r) to others (o) on the file 'test.txt'. This would be done like this:

chmod o+r file.txt

You want to rip (-) the owner group (g) of the right to execute (x) the program '/usr/bin/runme':

chmod g-x /usr/bin/runme

(Most likely you have to be 'root' for this...).
You want to deny (-) everyone access (rwx) to the directory 'secure' except to its owner:

chmod go-rwx secure

'chmod' knows some more useful switches, one of which is 'a' (for 'all'). Thus

chmod a+r test.txt

would grant 'read' rights to the user, the owner group and others.
Another one is the 's' switch for setting the UID or GID:

chmod a+x,u+s file

will set 'file' to 'setUID root' and executable by everyone.
Like 'chown', you can run 'chmod' recursively using the '-R' option (capital 'R'!). But read the warning below!

'chmod' also accepts defining rights by a octal triplet: '4' means 'read', '2' means 'write and '1' 'execute'. If one of these is not granted, its value becomes '0'. A leading fourth cipher may set 'setuid' ('4'), 'setgid' ('2') or the 'sticky bit' ('1'):

chmod 750 file

sets the owner right on [file] to read + write + execute (4+2+1=7), the group right to read + execute (4+0+1=5), everyone else has no rights at all (0+0+0=0).

Is there a difference between those two methods? Yes. The first method sets rights relative, the second absolute.
Example:

ls -l some.txt
-rw-r----- (...) some.txt

Now assume you want to grant 'others' the 'read' right to this file. With the first method, you'd do

chmod o+r some.txt

and you get

With the second method, you get a different result when applying the same:

chmod 444 some.txt
-r--r--r-- (...) some.txt

The first method leaves the 'write' right of the owner untouched. When using the second method, you always have to specify the absolute permissions for owner, group and others to get the desired result, in this case

chmod 644 some.txt

It might be better you concentrate on one method to avoid mixups.

section index top

Popular Cockups With Permissions

Handle permissions with care! They are an integral part of Linux' security concept and may cause you some trouble if applied thoughtlessly. Some examples:

chmod -R a-x text. This is a very popular one. You have copied a directory called 'text' from a MS Windows partition. Due to discrepancies in file handling all the files in this directory have the execution bit set (x). "No problem" you think and execute this command. Next time you want to switch into this directory, you just get

bash: cd: text: Permission denied

You 'su' to the root account and try again:

bash: cd: text: Permission denied

What the ...? Well, you did not only remove the execution bit from the files in the 'text' directory but also from the directory itself! Which means that no one - even 'root' - is allowed to go into this directory anymore! Just set the execution bit on the directory again:

chmod ug+x test

If you have a directory structure which contains files you want to strip recursively of the execution bit, but want to prevent 'chmod' from changing the directory bits, too, you will need something like this:

find . -type f -exec chmod a-x {} \;

This will find all normal text files ('-type f') and run ('-exec') 'chmod a-x' on them.

chmod a+rw /dev/.... A popular 'trick' to circumvent collisions with permissions set on device files. Generally one must be very careful in granting rights to the 'others' group. To this group belongs everyone, may he be a legal guest on your box or a filthy intruder! There is usually something wrong a program's configuration if you feel the urge to do this step. If there is absolutely no other way, it is far better to proceed like this:

1) 'su' to 'root'. Run chmod g+rw,o-rwx on the offending device file.
2) Run chgrp group on the same file.
3) Add the user to the corresponding group entry in '/etc/group'.

The same goes for setUID root programs. If you feel you must set a program 'uid root', proceed like I have outlined in the article on PPP.

Notice that changing the permissions on device files is likely to either not work at all or to only have temporary effect, either due to devfs or to PAM.

Executing 'chown' before 'chmod'. This is a bad idea because 'chmod' reverts any changes made by 'chown'. 'chmod' sets 'user' and 'group' of the file corresponding to the GID and UID of the person who ran 'chmod'. So run 'chmod' first and then 'chown'!

section index top

No need to panic now, all this sounds much more complicated than it actually is. And in case you're wondering: yes, all those cockups happened to me, too (and many, many more ;-)).