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
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.
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.
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.
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.
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.
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.
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
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.
- 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.
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.
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
Privacy policy
Contact: helpdesk