Department of Engineering

IT Services

Unix groups and file permissions

The early part of this document is for users wanting to know more about permissions and groups. Later on there's information aimed more at teaching staff and administrators

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

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

The first column of this output consists of 10 characters. The first shows what sort of file it is - a directory (in which case the character which be 'd'), a plain file (as here, the character being '-'), etc. The other 9 characters form 3 triplets. The first triplet shows read, write, and execute permissions for the owner of the file. The other 2 triplets show what permissions fellow group members and others have. The easiest way to interpret and change these permissions is to make use of a graphical (rather than command line) interface to Unix.

permissionspermissions

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

What do the rwx permissions mean for directories? A directory is just a list of entries, so

  • 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.
directory tree diagram

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

Note that it's not the ownership of the file that determines whether a user can remove it, but the writability of the directory that the file's in.

Changing the permissions of a file

Only the owner of a file (or the system administrator) can change permissions. For individual files and directories, the graphical method is much the easiest to use - just click on the ticks and blanks, then press the Accept button. The Recursive folders option lets you change permissions of a whole tree of files. The command line alternative is chmod - here are some examples of use

  • 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.

Use chmod with care - if you make a mistake you might make all your files editable by everyone. Be especially careful when using the '-R' option - it can have far-reaching effects when you have symbolic links in the directory.

Changing a file's group

The chgrp command can be used to change the group of one of your files but you can only change it to a group you belong to.

  • 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

If you want files created in a particular directory to always belong to a certain group, you can avoid having to use chgrp repeatedly by setting up the directory in a special way. If you have a directory called foodir and you'd like all the files created there to be in the partIa1 group you can do the following (if you belong to partIa1)

   chgrp partIa1  foodir
   chmod g+s      foodir

umask

There's an alternative to retrospectively changing files' permissions - using the umask command you can arrange for new files to automatically have the desired permissions.

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 - /groups - devoted to shared space. The idea is that each group has a directory somewhere under /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 /groups will have to be set up by the administrators.

Account Administration

Groups and start environment sare set up by mailing helpdesk. IIA project leaders can let students arrange themselves into groups if they ask tl136 to create a student groups page for them.

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.

  • © Cambridge University, Engineering Department, Trumpington Street, Cambridge CB2 1PZ, UK (map)
    Tel: +44 1223 332600, Fax: +44 1223 332662
    Contact: helpdesk