Department of Engineering

Unix groups and file permissions

Introduction

In Unix, a user's access to files is determined by the permissions set on the file and its parent folders, and the identity of the user. Each user has an identifier (a login name - type whoami to find yours). Also, each user belongs to one or more groups (type groups to see which groups you belong to) but is only in one group at a time. Typing id displays all the identification information about the user - the gid entry shows the user's current group.

When a user creates a file, it is owned by the user and belongs to the user's current group. Try

  touch cabbage
  ls -l cabbage

to create a file and display details about the file. You'll see that there are many details. For now just check that column 3 shows who owns the file and column 4 shows what group owns the file.

Permissions

Files are not simply readable or non-readable - independent read/write/execute controls can be set for the file-owner, the people belonging to the file's group, and all other users. This information is shown in the 1st column of ls -l's output. If you type ls -l /etc/passwd you'll get something like -rw-r--r-- 1 root root 175939 May 10 00:22 /etc/passwd The graphical interface (shown right) also lets you see the permission in this traditional way if you select the right option

If you click with the right mouse-button on a file and select the Properties menu option, then the Permissions tab, you'll see something like the panel in the left, which has buttons to selectively control access for different categories of user. If you click in the same way on a folder, you'll get a panel more like the one on the right. The execute permission is interpreted differently for folders, as described in the next section.

Directories/Folders

• if you can read a directory you can list the contents of that directory, so ls would work as expected.
• If you can write to directory you can change the contents of that directory - add and remove files
• For directories, the x flag means that the directory can be searched - this means that even if the user can't read the directory (i.e. they can't list its contents) they can still access the files there if they know their names.

In this situation, the owner (tpl) can read all the files people in group divf can do "ls dir1" to list the files in the directory. They can read file1 and file2 but not file3 other users will get an "unreadable" message if they try "ls dir1" but if they type "more dir1/file1" they'll be able to read the file. They won't be able to read file2 or file3

Changing the permissions of a file

• chmod a+r foo - let all users read foo
• chmod go-r foo - stop people in the file's group, and other users from reading the file
• chmod u+x foo - make the file executable for the owner
• chmod -R a+r foodir - let all users read foodir and all the files and directories under foodir.

Changing a file's group

• chgrp partIa1 foo - puts the foo file into the partIa1 group
• chgrp -R partIa1 foodir - puts the foodir directory and everything under it into the partIa1 group

   chgrp partIa1  foodir
   chmod g+s      foodir

umask

When a user creates a file it will be given default permissions. On the Teaching System those permissions give the user (but no-one else) read/write permission on their regular files and read/write/execute permission on their directories. These default permissions are set up in a configuration file at login by calling umask. If you type umask -S you will see your current settings. By default you should get u=rwx,g=,o=.

You can change this behaviour so that by default any new files you make can be read by anyone, or only by those in your current group. For example, typing umask u=rwx,g=rx lets group members read and execute your files.

Note that umask affects the behaviour of all future processes started from the window where umask was typed. It has no effect on programs which are already running.

Examples

• WWW files - One situation where file permissions matter is when you're putting files on the WWW. If user abc123 puts a file (foo.html say) in a folder called public_html in their Teaching System home directory it will appear on the WWW as http://www2.eng.cam.ac.uk/~abc123/foo.html as long as the permissions are ok. For everyone to read foo.html not only must the file itself be readable by all, but the directories leading down to the file must be traversable too. One way for abc123 to do this is the following
  • chmod a+r ~/public_html/foo.html - to make the file readable. The '~' symbol is shorthand for 'home directory'.
  • chmod a+rx ~/public_html
  • chmod a+x ~ - this makes the public_html directory available to all, but stops others listing what's in abc123's home directory.
• Students groups -
Students are put into groups for some courses (for example all 1st years are put into lab-group pairs called partIa1, partIa2, etc). To make file-sharing as transparent as possible, some start environments call chmod so that files which students create are automatically readable by others in their group. Sometimes directories are set up automatically by the start environment with group-ownership and permissions to facilitate sharing.

Letting students share files just for reading is easier than letting students change files written by others.

• Sharing files for reading only - Students can create files in their usual disc-space. They need to ensure that the files are group-readable and that the directories leading down to the files can be traversed by others in the group. This can be set-up automatically by a start environment.
• Sharing files for reading and writing - Letting files owned by one user to be in a directory of another user very easily leads to quota and permission trouble. On the teaching system we have an area - /homes/groups - devoted to shared (but still quota'd) space. The idea is that each group has a directory somewhere under /homes/groups and links are created between their usual space and the shared space. These links can be created automatically by a start environment, but the area in /homes/groups will have to be set up by the administrators.

Account Administration

Groups are set up by user-admin. start environments are set up by teaching-support. IIA project leaders can let students arrange themselves into groups if they ask tpl to create a student groups page for them - it will make life easier for user-admin too.

ACL

Since 2008 we've been using ACLs (Access Control Lists) to control access to some files (usually files used by groups for projects). The ACL control override the usual unix controls. To see if your files are under ACL control, open a terminal window and use ls ... as before. If there's a + after the permission flags in the output, the files are under ACL control. For example, the following files are ACLd

   drwxrws---+ 6 bin softdes1 4096 2009-05-15 11:23 softdes1
   drwxrws---+ 6 bin softdes2 4096 2009-05-15 11:25 softdes2

These displayed Unix permissions aren't to be trusted. To get the ACL information about a file or folder, use the getfacl command. For example, typing

   getfacl softdes1

gives informations about who can do what to the softdes1 folder.