Sidebar: UNIX Filesystem and Permissions Revisited
The security of the Unix filesystem is based on a number
of key factors.
First, the identity of the user is important. This identity
consists of
two elements, a unique user id (uid) and a group id
(gid). The uid is a
number that uniquely identifies the user on the particular
system. A
user always belongs to at least one group, but can be
a member of more
than one group. Group ids are normally established along
lines similar
to the departments within the organization.
All files in a UNIX filesystem have two elements of
ownership. Each file
is owned by a specific user and also belongs to a group.
Permissions
relative to files are designated as read (shown as r
in listings), write
(shown as w in listings), and execute (shown as x in
listings). Read
permission allows you to look at the contents of a file,
but not edit,
change, or delete the file. Write permission allows
you to take those
actions.
Thus, when you do a long listing of a file using ls
-l, these three
permissions are reflected for the user, the group, and
everyone else
(referred to as "other"), preceded by a single
character designator for
the type of file. If a permission is denied, a dash
appears in that
space, as shown below. Execute permission on directories
has a special
meaning. It means that the directory file can be searched.
If the
directory is also readable, then files in the directory
can be listed
using ls or other utilities.
All programs that are started by a user normally run
under his or her
uid and gid. Exceptions to this rule are the setuid
and setgid programs
that execute under the uid or gid of the user or group
that owns the
file. If either of these permission bits are set, the
x in the
permissions listing is replaced by an s.
An example of a setuid program is the passwd program
that you can use to
change your password. The password is stored in the
file /etc/passwd,
and this file is normally writeable only by the superuser
or root. So,
if a normal user wants to write a new password to this
file, it will
normally fail. By making this program setuid to root,
it will change its
identity to root and thus, can write the new password
in the passwd
file. The following listing shows you the protection
on the /etc/passwd
file and the security mask for the passwd program. In
this particular
example, taken from Solaris 2.4, the /etc/passwd is
not writeable at
all, but luckily the superuser can change this on the
fly.
bash$ ls -l /etc/passwd
-r--r--r-- 1 root sys 939 May 3 11:44 /etc/passwd
bash$
bash$ ls -l /usr/bin/passwd
-r-sr-sr-x 1 root sys 11680 Jul 16 1994 /usr/bin/passwd
bash$
The s listing for the setuid bit does not truly replace
the x bit, but
rather is a combination of both the x bit and an invisible
bit. If you
cleared the x bit on a setuid program, the s would change
into an S,
meaning that the invisible bit is set and the x bit
is cleared - an
invalid combination.
The setgid (set group id) bit for executable files has
the same meaning
as the setuid bit, but only for the gid under which
the program is
running. So, setgid bit will change the file's group
id to the group id
that owns that file. The effect of setting the group
id without
corresponding execute permission is UNIX implementation
dependent. Under
Solaris, for example, this bit will change its meaning
when the x bit is
cleared. In that case, mandatory locking applies to
that particular
file, and the representation in the ls output will change
from s to l.
The setgid bit also has a meaning when the related object
is a
directory. This, too, is implementation dependent. If
you set this bit
on a directory, all files created in this directory
will inherit their
group ownership from the group ownership of the directory
itself. This
behavior is derived from BSD UNIX and might not apply
to your particular
flavor.
|