Understanding Access Rights - www.linux-noob.com

Understanding Access Permissions
Using file/directory permissions can be a little bit tricky when you come from the Microsoft world. At some points I will say "root" or more correctly UID 0, these things are the same.

Main Utilities:
chmod - Change access permissions of files
chown - Change file owner and group

And for more experienced users:
stat - Display file or filesystem status

The access rights determine if a process can access a file in a particular method. These rights specify read, write and execute and are further controlled by user, group and other.

Quick glance at how file permissions look:

znx@loud $ 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 �, 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

Translating this into something more understandable leaves us with:

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

znx@loud ~/test $ ls -l
total 0
-rw-r--r--  1 znx users 0 Aug 28 01:37 file
znx@loud ~/test $ more file
znx@loud ~/test $ cp file file2
znx@loud ~/test $ 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.

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

As you can see znx can write to the file, however he cannot remove the 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.

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

As you can see, 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 0 is very special allowing complete unrestricted access to the whole file system irrespective of the permissions (you cannot lock UID 0 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.

znx@loud ~/test $ chmod u-r .
znx@loud ~/test $ ls
ls: .: Permission denied
znx@loud ~/test $ chmod u+r .
znx@loud ~/test $ 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.

znx@loud ~/test $ ls -ld .
drwxr-xr-x  2 znx users 72 Aug 28 02:05 .
znx@loud ~/test $ ls -l
total 0
-rw-r--r--  1 znx users 0 Aug 28 01:55 file
znx@loud ~/test $ su
Password: *******
loud test # cp /dev/null file2
loud test # 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
loud test # exit
znx@loud ~/test $ rm file2
rm: remove write-protected regular empty file `file2'? y
znx@loud ~/test $ 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.

znx@loud ~/test $ mkdir test
znx@loud ~/test $ touch test/file
znx@loud ~/test $ chmod 600 test
znx@loud ~/test $ ls -l test
drw-------  2 znx users 72 Aug 28 02:17 test
znx@loud ~/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 about 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.

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.