In Linux, objects such as files or folder or processes generally belong to the user who created or initiated them. There are some exceptions from this rule. For more information about the exceptions, refer to Chapter Access Control Lists in Linux (↑Reference). The group which is associated with a file or a folder depends on the primary group the user belongs to when creating the object.
When you create a new file or
directory, initial access permissions for this object are set according to a
predefined scheme. As an owner of a file or directory, you can change the
access permissions to this object. For example, you can protect files holding
sensitive data against read access by other users and you can authorize the
members of your group or other users to write, read, or execute several of
your files where appropriate. As root
, you can also
change the ownership of files or folders.
Three permission sets are defined for each file object on a Linux system. These sets include the read, write, and execute permissions for each of three types of users—the owner, the group, and other users. You can view and change the access permissions of a file or folder in the file managers of your desktop or in a shell (see Section 8.5, “Modifying File Permissions”).
The following example shows the output of an
ls
-l
command in a shell. This
command lists the contents of a directory and shows the details for each file
and folder in that directory.
Example 7.1. Access Permissions For Files and Folders
-rw-r----- 1 tux users 0 2006-06-23 16:08 checklist.txt -rw-r--r-- 1 tux users 53279 2006-06-21 13:16 gnome_quick.xml -rw-rw---- 1 tux users 0 2006-06-23 16:08 index.htm -rw-r--r-- 1 tux users 70733 2006-06-21 09:35 kde-start.xml -rw-r--r-- 1 tux users 47896 2006-06-21 09:46 kde_quick.xml drwxr-xr-x 2 tux users 48 2006-06-23 16:09 local -r-xr-xr-x 1 tux users 624398 2006-06-23 15:43 tux.jpg
As shown in the third column, all objects belong to user tux
. They are assigned to the group
users
which is the primary group the user
tux
belongs to. To retrieve the access permissions the first
column of the list must be examined more closely. Let's have a look at the
file kde-start.xml
:
Type |
User Permissions |
Group Permissions |
Permissions for Others |
|
|
|
|
The first column of the list consists of one leading character followed
by nine characters grouped in three blocks. The leading character indicates
the file type of the object : in this case, the hyphen
(–
) shows that
kde-start.xml
is a file. If you find the
character d
instead, this shows that the object is a
directory (like local
in the example above). The next
three blocks show the access permissions for the owner, the group and other
users (from left to right). Each block follows the same pattern: the first
position shows read permissions (r
), the next position shows write permissions
(w
), the last one shows
execute permission (x
). A lack of either permission is
indicated by -
. In
our example, the owner of kde-start.xml
has
read and write access to the file but cannot execute it. The
users
group can read the file but cannot write or
execute it. The same holds true for the other users as shown by the third
block of characters.
Access permissions have a slightly different impact depending on the type of object they apply to: file or directory. The following table shows the details:
Table 7.2. Access Permissions For Files And Directories
Access Permission |
File |
Folder |
---|---|---|
Read (r) |
Users can open and read the file. |
Users can view the contents of the directory. Without this
permission, users cannot list the contents of this directory with
ls |
Write (w) |
Users can change the file: They can add or drop data and can even delete the contents of the file. However, this does not include the permission to remove the file completely from the directory as long as they do not have write permissions for the directory where the file is located. |
Users can create, rename or delete files in the directory. |
Execute (x) |
Users can execute the file. This permission is only relevant for files like programs or shell scripts, not for text files. If the operating system can execute the file directly, users do not need read permission to execute the file. However, if the file must me interpreted like a shell script or a perl program, additional read permission is needed. |
Users can change into the directory and execute files there. If they do not have read access to that directory they cannot list the files but can access them nevertheless if they know of their existence. |
Note that access to a certain file is always dependent on the correct combination of access permissions for the file itself and the directory it is located in.