To prevent all users from being able to access all files on the system, unix records information about who creates files and also who is allowed to access them later.
Each user has a unique username or loginname together with
a unique user id or uid. The user id is a number, whereas the
login name is a text string -- otherwise the two express the same information. A
file belongs to user A if it is owned by user A. User A then decides
whether or not other users can read, write or execute the file by setting the
protection bits or the permission of the file using the
command chmod.
In addition to user identities, there are groups of users. The idea of a
group is that several named users might want to be able to read and work on a
file, without other users being able to access it. Every user is a member of at
least one group, called the login group and each group has both a
textual name and a number (group id). The uid and gid
of each user is recorded in the file /etc/passwd (See chapter 6).
Membership of other groups is recorded in the file /etc/group or on
some systems /etc/logingroup.
The following output is from the command ls -lag executed on a
SunOS type machine.
lrwxrwxrwx 1 root wheel 7 Jun 1 1993 bin -> usr/bin -r--r--r-- 1 root bin 103512 Jun 1 1993 boott drwxr-sr-x 2 bin staff 11264 May 11 17:00 dev drwxr-sr-x 10 bin staff 2560 Jul 8 02:06 etc drwxr-sr-x 8 root wheel 512 Jun 1 1993 export drwx------ 2 root daemon 512 Sep 26 1993 home -rwxr-xr-x 1 root wheel 249079 Jun 1 1993 kadbb lrwxrwxrwx 1 root wheel 7 Jun 1 1993 lib -> usr/lib drwxr-xr-x 2 root wheel 8192 Jun 1 1993 lost+found drwxr-sr-x 2 bin staff 512 Jul 23 1992 mnt dr-xr-xr-x 1 root wheel 512 May 11 17:00 net drwxr-sr-x 2 root wheel 512 Jun 1 1993 pcfs drwxr-sr-x 2 bin staff 512 Jun 1 1993 sbin lrwxrwxrwx 1 root wheel 13 Jun 1 1993 sys->kvm/sys drwxrwxrwx 6 root wheel 732 Jul 8 19:23 tmp drwxr-xr-x 27 root wheel 1024 Jun 14 1993 usr drwxr-sr-x 10 bin staff 512 Jul 23 1992 var -rwxr-xr-x 1 root daemon 2182656 Jun 4 1993 vmunnix
The first column is a textual representation of the protection bits for each
file. Column two is the number of links to the file (See exercises below). The
third and fourth columns are the user id and group id and the remainder show the
file size in bytes and the creation date. Notice that the directories /bin
and /sys are symbolic links to other directories.
There are sixteen protection bits for a UNIX file, but only twelve of them can be changed by users. These twelve are split into four groups of three. Each three-bit number corresponds to one octal number.
The leading four invisible bits gives information about the type of file: is
the file a plain file, a directory or a link. In the
output from ls this is represented by a single character: -,
d or l.
The next three bits set the so-called s-bits and t-bit which are explained below.
The remaining three groups of three bits set flags which indicate whether a file can be read `r', written to `w' or executed `x' by (i) the user who created them, (ii) the other users who are in the group the file is marked with, and (iii) any user at all.
For example, the permission
Type Owner Group Anyone d rwx r-x ---
tells us that the file is a directory, which can be read and written to by the owner, can be read by others in its group, but not by anyone else.
Note about directories. It is impossible to
cd to a directory unless the x bit is set. That is,
directories must be `executable' in order to be readable.
Here are some examples of the relationship between binary, octal and the textual representation of file modes.
Binary Octal Text 001 1 x 010 2 w 100 4 r 110 6 rw- 101 5 r-x - 644 rw-r--r--
It is well worth becoming familiar with the octal number representation of these permissions.
The chmod command changes the permission or mode of a
file. Only the owner of the file or the superuser can change the permission.
Here are some examples of its use. Try them.
# make read/write-able for everyone chmod a+w myfile # add the 'execute' flag for directory chmod u+x mydir/ # open all files for everyone chmod 755 * # set the s-bit on my-dir's group chmod g+s mydir/ # descend recursively into directory opening all files chmod -R a+r dir
When a new file gets created, the operating system must decide what default
protection bits to set on that file. The variable umask decides
this. umask is normally set by each user in his or her .cshrc
file (see next chapter). For example
umask 077 # safe umask 022 # liberal
According the UNIX documentation, the value of umask is `XOR'ed
(exclusive `OR') with a value of 666 & umask for plain
files or 777 & umask for directories in order to find out the
standard protection. Actually this is not quite true: `umask' only
removes bits, it never sets bits which were not already set in 666.
For instance
umask Permission 077 600 (plain) 077 700 (dir) 022 644 (plain) 022 755 (dir)
A unix program is normally executed by typing its pathname. If the x
execute bit is not set on the file, this will generate a `Permission denied'
error. This protects the system from interpreting nonsense files as programs. To
make a program executable for someone, you must therefore ensure that they can
execute the file, using a command like
chmod u+x filename
This command would set execute permissions for the owner of the file;
chmod ug+x filename
would set execute permissions for the owner and for any users in the same group as the file. Note that script programs must also be readable in order to be executable, since the shell has the interpret them by reading.
These two commands change the ownership and the group ownership of a file. Only the superuser can change the ownership of a file. Only a member of the group or the superuser can change the group ownership of a file.
The s and t bits have special uses. They are
described as follows.
Octal Text Name 4000 chmod u+s Setuid bit 2000 chmod g+s Setgid bit 1000 chmod +t Sticky bit
The effect of these bits differs for plain files and directories and differ
between different versions of UNIX. You should check the manual page man
sticky to find out about your system! The following is common behaviour.
For executable files, the setuid bit tells UNIX that regardless of who
runs the program it should be executed with the permissions and rights of
owner of the file. This is often used to allow normal users limited access to
root privileges. A setuid-root program is executed as
root for any user. The setgid bit sets the group execution rights
of the program in a similar way.
In BSD unix, if the setgid bit is set on a directory then any new files created in that directory assume the group ownership of the parent directory and not the logingroup of the user who created the file. This is standard policy under system 5.
A directory for which the sticky bit is set restrict the deletion of files
within it. A file or directory inside a directory with the t-bit set can only be
deleted or renamed by its owner or the superuser. This is useful for directories
like the mail spool area and /tmp which must be writable to
everyone, but should not allow a user to delete another user's files.
Page from www.geocities.com/avis_unix