Understanding Access Rights

Whilst using the earlier versions of Windows (which were not built to be multi-user) access was granted across the board to all users. Now with newer versions of Windows access can be granted and denied to non-admin accounts. However most users still use Windows as the administrator and therefore access control is still something a little foreign to users that switch over to GNU/Linux.

It can be a little tricky when it comes to setting, removing and altering permissions and even more so if you don't understand what they mean or do. It can even be damaging to your system if you alter permissions incorrectly or accidently (hence when you run commands as 'root' double check).

It should be noted that 'root' or the administrator of a GNU/Linux system can also be referred to as UID 1 (userid 1) and I will refer to it correctly as UID 1 rather than root during this. The name 'root' is only a name connected to the userid and it can be anything (although it very rarely is).

Basic Commands

To alter the permissions on files within Linux requires the use of a few simple commands:

chown

Changes file owner and group.

chown newowner file
chown newowner:newgroup file

chgrp

Changes the group of the file.

chgrp newgroup file

stat

Display filesystem status of the file.

stat file

chmod

Changes the access permissions of file. This one is a little more tricky and I will explain more about the definitions in the next section.

chmod u+r file
chmod og-rw+x file
chmod u+r,og= file

File Permissions

When you attempt to access a file you will do so with a program. The access rights will be determined by the access rights that this program has. Keeping in with the correct terms, the access rights are determined by the process accessing the file.

These rights specify read, write and execute and are further controlled by user, group and other.

$ ls -l file
-rw-r-----  1 znx users 0 Aug 28 01:37 file

Taking each bit as it goes:

-

This represents the file type, file (-) and directory (d) are all you need right now, there are more but it will just confuse matters.

rw-

The first three indicate the permissions for the file owner (znx), read (r), write (w) and execute (x). In this case, znx has read and write permissions.

r--

The middle three indicate the permissions for the file group (users). In this case members of the users group have read access.

---

The last three indicate the permissions for users that aren't the owner or within the group of the file are dealt with here. So no access rights are granted to anyone that isn't user znx or those outside of the users group.

So just what does read, write or execute access mean. Lets continue translating this into something more understandable:

read

Can we read from the file. This implies that the file can be copied.

$ ls -l
total 0
-rw-r--r--  1 znx users 0 Aug 28 01:37 file
$ more file
$ cp file file2
$ ls -l
total 0
-rw-r--r--  1 znx users 0 Aug 28 01:37 file
-rw-r--r--  1 znx users 0 Aug 28 01:37 file2

As you can see, znx has read access to file, so he can read it and copy it.

write

Can we alter the contents of the file. This also includes making the file empty (or 0 in size) but doesn't include deleting the file.

$ chmod u-w .
$ ls -l file
-rw-r--r--  1 znx users 0 Aug 28 01:37 file
$ nano file
$ ls -l file
-rw-r--r--  1 znx users 5 Aug 28 01:53 file
$ rm file
rm: cannot remove `file': Permission denied
$ cat /dev/null > file
$ chmod u+w .

As you can see znx can write to the file, however he cannot remove he file and finally he is able to empty the file. Note the chmod commands before and after the test are to prove that the write permissions on the file do not indicate the ability to remove the file.

execute

Can we execute the contents of the file.

$ ls -l file
-rw-r--r--  1 znx users 0 Aug 28 01:55 file
$ ./file
-bash: ./file: Permission denied

No execute permissions exist on the file (no x) and therefore bash tells us permission denied.

How the Kernel Sees It

When you attempt to access a file it will be made by a process acting for you (i.e. with your user). When the kernel is determining if you can access a particular file it will:

Check if the UID of the process 1

If so, no other checks will be made and access will be granted. UID 1 is very special allowing complete unrestricted access to the whole file system irrespective of the permissions (you cannot lock UID 1 out from anywhere).

UID of the process

If this matches the owner UID of the file then the kernel will continue to check if the user access rights of the file allow for the type of access requested.

GID of the process

If this matches the GID of the file the kernel will continue to check the group access rights.

No UID/GID match

This case indicates that the kernel should consider if other access rights permit the requested type of access. "Other" is sometimes called world or global rights.

Directory Permissions

Access rights for files have slightly differing meanings when applied to directories (and other file system objects). Here is for directories:

read

This means that a listing of the directory can be made, allowing all the information on the files within to be found.

$ chmod u-r .
$ ls
ls: .: Permission denied
$ chmod u+r .
$ ls
file

Removing the read permissions on the current directory (.) stops us from being able to read the directory.

write

This means that the contents of the directory can be changed. In other words, it allows you to create and delete files within the directory. It is therefore possible to delete files that you don't own or cannot read.

$ ls -ld .
drwxr-xr-x  2 znx users 72 Aug 28 02:05 .
$ ls -l
total 0
-rw-r--r--  1 znx users 0 Aug 28 01:55 file
$ su
Password: *******
# cp /dev/null file2
# ls -l
total 0
-rw-r--r--  1 znx  users 0 Aug 28 01:55 file
-rw-r--r--  1 root root  0 Aug 28 02:05 file2
# exit
$ rm file2
rm: remove write-protected regular empty file `file2'? y
$ ls -l
total 0
-rw-r--r--  1 znx users 0 Aug 28 01:55 file

In this example, we become the 'root' user and create a file. As you can then see the user is able to delete the file even though it is owned by root (we are given a warning by the rm command but we can still delete it).

execute

This allows the kernel to search the directory for a files but does not allow an other process to view the directory.

$ mkdir test
$ touch test/file
$ chmod 600 test
$ ls -l test
drw-------  2 znx users 72 Aug 28 02:17 test
$ ls test
ls: test/file: Permission denied

As you can see, removing the execute permissions removed the ability for "ls" to view the directory contents.

Issues with Basic File Access

The basic linux access system suffers from the disadvantage that if you want to make a file accessible to another user you will make it accessible to everyone in the same group or, worse, to everybody.

Access Control Lists

The solution to the issues with the basic access system that provides the majority of control for linux was the extended Access Control Lists or ACLs for short. ACLs allowed extended lists of information regarding access to a file or directory thus removing the need to open files up to group/world.

You note that I call them 'extended' ACLs, what we covered already is the standard Linux permissions which are known as 'minimal' ACLs.

getfacl

Allows you to view the ACLs.

getfacl file

setfacl

Allows you to set or modify the ACLs.

setfacl -m group:example:rwx file

Lets lead with an example.

$ mkdir -m 750 directory
$ ls -ld directory
drwxr-x--- 2 znx users 512 2005-09-27 07:35 directory/
$ getfacl directory
# file: directory
# owner: znx
# group: users
user::rwx
group::r-x              #effective:r-x
mask:r-x
other:---

You can see that the getfacl command has provided us with information regarding the current permissions on the directory. Now lets extend the permissions to the directory.

$ setfacl -m user:www:rwx directory
$ ls -ld directory
drwxr-x---+ 2 znx users 512 2005-09-27 07:35 directory/
$ getfacl directory
# file: directory
# owner: znx
# group: users
user::rwx
user:www:rwx            #effective:r-x
group::r-x              #effective:r-x
mask:r-x
other:---

You can see the small '+' at the end of the permissions information from 'ls', this indicates that an extended ACL exists. Checking it with getfacl we can see that the user www now has effective permissions of r-x (due to the mask which removes w access).

You can also setup an inherited ACL which is called the 'default' ACL.

$ setfacl -d -m group:apache:r-x directory
$ getfacl directory
# file: directory
# owner: znx
# group: users
user::rwx
user:www:rwx            #effective:r-x
group::r-x              #effective:r-x
mask:r-x
other:---
default:user::rwx
default:group::r-x
default:group:apache:r-x
default:mask::r-x
default:other::---

As you can now see the default ACL is now setup, this means that all the files created under this directory will gain this ACL on creation.

$ mkdir directory/sub
$ getfacl directory/sub
# file: directory
# owner: znx
# group: users
user::rwx
user:apache:rwx         #effective:r-x
group::r-x              #effective:r-x
mask:r-x
other:---
default:user::rwx
default:group::r-x
default:group:apache:r-x
default:mask::r-x
default:other::---

How the Kernel Sees it

Once more lets walk through how the kernel handles extended ACLs. Each of these only refers to the user/group handling, remember that permissions based on these would be tested on each step (bar the first special case).

Check if the UID of the process is 1

Special case for root user.

Check if the UID of the process is the owner.

Allow access for the owner.

Check if the UID of the process matches one of the named user entries.

Additional named users are treated as owners.

Check if the GID of the process matches the owning group.

Allow access for the owning group.

Check if the GID of the process matches one of the named group entries.

Additional groups are treated as the owning group.

Check the 'other' permissions.

If global/world permissions are granted.

Otherwise access is denied.

Poor users :)

Conclusions

Most users may not be aware of extended ACLs and the benefit that they provide, taking a simple example from my work.

We allow individuals the ability to have some private webspace allow with their account (~user/public_html). To allow access to this directory for the web server we would require the permissions to be set to:

drwxr-xr-x  17 fac075   com   512 2005-09-29 08:36 public_html/

As you can see I have just made my public_html folder accessible to the whole of the University account, not exactly what I'd like. So instead what we do is that we use extended ACLs:

drwxr-x---+ 17 fac075   com   512 2005-09-29 08:36 public_html/

Now the directory is closed to all but myself and my group, checking the ACLs:

$ getfacl public_html/
# file: public_html/
# owner: fac075
# group: com
user::rwx
user:www:r-x            #effective:r-x
group::r-x              #effective:r-x
mask:r-x
other:---

You can see that now the www user has effective permissions of r-x and therefore can still access the closed directory. This is the real benefit of ACLs in a working example.