|
Linux knows users by their accounts. In order
to use your system, you have to tell it who you are (i.e. which account you
want access to) by 'logging in'. Having done that you will be taken to your
account's home directory ('/home/account'), where you can do pretty
much what you want.
Each UNIX system has one 'human' account already built-in,
and that's the 'root' account. The 'root' account is special in several ways:
its home directory is '/root' and whoever is 'root' has total control over
the system.
The basic idea behind this scheme is to allow separating
the daily use of an operating system from system administration. Among other
things this prevents an error made during normal use of the operating system
to have any severe impact on the operating system itself.
It also allows for different users on the same system. These additional users
do not have to be human: system services often have accounts of their own,
so that they don't have to be run via the 'root' account. This way a mis-configured
system service is prevented from having a major impact on the operating system
itself, too.
Now, how does the operating system determines who is
allowed to do what? This is where permissions kick in.
Each file on a UNIX system has a permission setting,
represented by the first ten characters in a file listing and the ownership
names:
ls -l file
-rw-rw-r-- (...) owner group (...) file
Everything in UNIX is managed via files, even access
to devices (via the device files in '/dev') like printers, modems, sound
cards etc. If you do not have the permission on a file which represents a
device, you can't use that device.
The first concept of permissions is ownership.
You either own a file or a directory you have created or that has been handed
over to you by using the 'chown' command (short for 'change owner', more
on this command later). If you own a file, you can do whatever you want with
it, usually.
But often more than one account needs access to a file
or device. Changing the ownership of this file every time someone else needs
access to it would be very tedious to say the least. This is why ownership
is not only provided for single accounts but also for groups.
Groups are defined in '/etc/group', an entry in this file looks like this:
group_name:x:group_ID:group_members
To see a list of groups your current account is a member
of, use the command
groups
So, if you are member of a group and that group has
permissions on a file, you can do something with that file, even if you are
not its owner.
An average UNIX system has some 60.000 files and more.
A majority of them has to to accessible in some way by all the users on a
system. One way to achieve this could be to create an 'catch-all' group which
would unite all the accounts on a system and assign all the files in question
to this group. But since permissions do not only decide who has
access to a file, but also what kind of access, such a group would
defeat the purpose of the system: there are many cases in which members of
a certain group need more rights on a file, but others need limited access
to this file, too. This is the rationale behind the others 'group'.
Permissions on a file given to this particular group are granted for all
accounts on a system. Have a look at the example again:
ls -l file
-rw-rw-r-- (...) owner group (...) file
Characters 2-4 ('rw-') describe the permissions of the
owner, characters 5-7 ('rw-') describe the permissions of the owner group,
and characters 8-10 describe the permissions of everyone else on that file.
Let's move on from the 'who' part of permissions to
the 'what' part. There's pretty much you can do with (or to) a file: you
can read it, change it, delete it or - in some cases - execute it. Permissions
decide which of these actions can be taken, too. This is the concept ofaccessibility.
Permissions on access can be granted in three ways:
permission to read (marked with 'r'), permission to write and delete (marked
with 'w') and permission to execute (marked with 'x'). In the above example
the owner and the owner group have the permissions to read and change / delete
the file. Everyone else might read the file, but is not allowed to change
its contents.
No one may execute this file. In contrast to operating systems like Windows
9x, a file must not only contain executable content (either binary or script)
but it must also have the execution bit set. This allows to exclude accounts
from running the file or program, usually for system security reasons. Even
'root' can't execute files without the execution bit, but he or she can make
every file executable. Of course, if this file doesn't contain executable
content, you still won't be able to execute it, regardless of the execution
bit.
Directories also feature permissions. Due to their nature,
the permission bits have a slightly different meaning: 'r-x' means being
able to list directory contents and to make this directory the working directory.
'rwx' means being allowed to put into or remove files from that directory.
Every other combination of permissions will not
allow you to access this directory.
(Notice that with the introduction of the Mandrake
Security Tools (MSEC) in ML 7, default permissions on files may differ
widely depending on the overall security level chosen during installation
or later using 'DrakConf'.)
 section index  top
It is a distinguishing mark of the Unix/Linux concept
of computing to manage all input/output operations via files. If
you send a file to your printer for example, you in fact send it to the file
'/dev/lp0'. If you are connected to net via a modem all data is written and
read from '/dev/ttyS0' (or S1/S2/S3).
The upshot is that either you or the program you execute need permission
to read and write that file. Without this, it won't work. The same applies
to directories: you can't run a program which resides in a directory you
don't have access to or which needs write access to a directory you don't
have write access to. Many configuration problems are simply due to wrong
permissions. Checking permissions is an important step in troubleshooting.
Now you might say that since you are the only user on
your machine, 'why fiddling around with all this permissions stuff, I just
stay root, so I am allowed to do everything'.
This is precisely the reason why you shouldn't do that. A single
wrong root command can blow your system to pieces, whereas as a simple user
you just can't break anything vitally important. Especially if you
are new to Linux you really should use this mechanism to protect yourself
from your errors.
But there is even more to that:
Most programs you start run with the permissions of the user that started
them. So if you started a program as a normal user and it runs berserk you
can normally kill it easily and it can't do any real damage because it has
no rights to do so. Now imagine the same with a program with root privileges...
I think you see the point.
The execute permission on a file indeed makes this file
executable. Many files of script languages like Perl or even simple shell
scripts rely on this. If you've downloaded a script and it just won't run,
check if the execution bit has been set (see next chapter).
Programs can run with a different user id (UID). Some
programs require root privileges even if they are started by a normal user
(like the X server via the Xwrapper in '/usr/X11R6/bin'), such programs are
indicated by an 's':
-rws--x--x 1 root root [...] /usr/X11R6/bin/Xwrapper*
(the asterisk sign '*' tells you that it is an executable
file).
However such programs pose a security threat since they
allow crackers to gain root access to a box using so-called overflow exploits.
Therefore it is advisable to keep the number of such programs as small as
possible and have an eye on security alerts. Notice that Linux won't execute
SUID shell scripts.
section index top
Confusing, isn't it? ;-)  Have a look at some practical examples...
|
