Red Hat System Administration I
- SectionInterpreting Linux File System Permissions
- Quiz: Interpreting Linux File System Permissions
- Managing File System Permissions from the Command Line
- Guided Exercise: Managing File System Permissions from the Command Line
- Managing Default Permissions and File Access
- Guided Exercise: Managing Default Permissions and File Access
- Lab: Controlling Access to Files
- Summary
Abstract
| Goal | Set Linux file-system permissions on files and to interpret the security effects of different permission settings. |
| Objectives |
|
| Sections |
|
| Lab |
Controlling Access to Files |
Objectives
After completing this section, you should be able to list file-system permissions on files and directories, and interpret the effect of those permissions on access by users and groups.
Linux File-system Permissions
File permissions control access to files. Linux file permissions are simple but flexible, easy to understand and apply, yet still able to handle most normal permission cases easily.
Files have three user categories to which permissions apply. The file is owned by a user, normally the one who created the file. The file is also owned by a single group, usually the primary group of the user who created the file, but this can be changed. Different permissions can be set for the owning user, the owning group, and for all other users on the system that are not the user or a member of the owning group.
The most specific permissions take precedence. User permissions override group permissions, which override other permissions.
In SectionFigure 7.1: Example group membership to facilitate collaboration, joshua is a member of the groups joshua and web, and allison is a member of allison, wheel, and web.
When joshua and allison need to collaborate, the files should be associated with the group web and group permissions should allow the desired access.
Three permission categories apply: read, write, and execute. The following table explains how these permissions affect access to files and directories.
Table 7.1. Effects of Permissions on Files and Directories
|
Permission |
Effect on files |
Effect on directories |
|---|---|---|
|
|
File contents can be read. |
Contents of the directory (the file names) can be listed. |
|
|
File contents can be changed. |
Any file in the directory can be created or deleted. |
|
|
Files can be executed as commands. |
The directory can become the current working directory. (You can cd into it, but also require read permission to list files found there.) |
Users normally have both read and execute permissions on read-only directories so that they can list the directory and have full read-only access to its contents. If a user only has read access on a directory, the names of the files in it can be listed, but no other information, including permissions or time stamps, are available, nor can they be accessed. If a user only has execute access on a directory, they cannot list file names in the directory. If they know the name of a file that they have permission to read, they can access the contents of that file from outside the directory by explicitly specifying the relative file name.
A file may be removed by anyone who has ownership of, or write permission to, the directory in which the file resides, regardless of the ownership or permissions on the file itself. This can be overridden with a special permission, the sticky bit, discussed later in this chapter.
Note
Linux file permissions work differently than the permissions system used by the NTFS file system for Microsoft Windows.
On Linux, permissions apply only to the file or directory on which they are set. That is, permissions on a directory are not inherited automatically by the subdirectories and files within it. However, permissions on a directory can block access to the contents of the directory depending on how restrictive they are.
The read permission on a directory in Linux is roughly equivalent to List folder contents in Windows.
The write permission on a directory in Linux is equivalent to Modify in Windows; it implies the ability to delete files and subdirectories. In Linux, if write and the sticky bit are both set on a directory, then only the file or subdirectory owner may delete it, which is similar to the Windows Write permission behavior.
The Linux root user has the equivalent of the Windows Full Control permission on all files. However, root may have access restricted by the system's SELinux policy using process and file security contexts. SELinux will be discussed in a later course.
Viewing File and Directory Permissions and Ownership
The -l option of the ls command shows detailed information about permissions and ownership:
[user@host~]$ls -l test-rw-rw-r--. 1 student student 0 Feb 8 17:36 test
Use the -d option to show detailed information about a directory itself, and not its contents.
[user@host ~]$ls -ld /homedrwxr-xr-x. 5 root root 4096 Jan 31 22:00 /home
The first character of the long listing is the file type, interpreted like this:
-is a regular file.dis a directory.lis a soft link.Other characters represent hardware devices (
bandc) or other special-purpose files (pands).
The next nine characters are the file permissions.
These are in three sets of three characters: permissions that apply to the user that owns the file, the group that owns the file, and all other users.
If the set shows rwx, that category has all three permissions, read, write, and execute.
If a letter has been replaced by -, then that category does not have that permission.
After the link count, the first name specifies the user that owns the file, and the second name the group that owns the file.
So in the example above, the permissions for user student are specified by the first set of three characters.
User student has read and write on test, but not execute.
Group student is specified by the second set of three characters: it also has read and write on test, but not execute.
Any other user's permissions are specified by the third set of three characters: they only have read permission on test.
The most specific set of permissions apply.
So if user student has different permissions than group student, and user student is also a member of that group, then the user permissions will be the ones that apply.
Examples of Permission Effects
The following examples will help illustrate how file permissions interact. For these examples, we have four users with the following group memberships:
| User | Group Memberships |
|---|---|
operator1 | operator1, consultant1 |
database1 | database1, consultant1 |
database2 | database2, operator2 |
contractor1 | contractor1, operator2 |
Those users will be working with files in the dir directory.
This is a long listing of the files in that directory:
[database1@host dir]$ls -latotal 24 drwxrwxr-x. 2 database1 consultant1 4096 Apr 4 10:23 . drwxr-xr-x. 10 root root 4096 Apr 1 17:34 .. -rw-rw-r--. 1 operator1 operator1 1024 Apr 4 11:02 lfile1 -rw-r--rw-. 1 operator1 consultant1 3144 Apr 4 11:02 lfile2 -rw-rw-r--. 1 database1 consultant1 10234 Apr 4 10:14 rfile1 -rw-r-----. 1 database1 consultant1 2048 Apr 4 10:18 rfile2
The -a option shows the permissions of hidden files, including the special files used to represent the directory and its parent.
In this example, . reflects the permissions of dir itself, and .. the permissions of its parent directory.
What are the permissions of rfile1?
The user that owns the file (database1) has read and write but not execute.
The group that owns the file (consultant1) has read and write but not execute.
All other users have read but not write or execute.
The following table explores some of the effects of this set of permissions for these users:
| Effect | Why is this true? |
|---|---|
|
The user |
User |
|
The user |
User |
|
The user |
User |
|
The users |
|
|
|
User and group |
|
The user |
User |
|
The user |
User |
|
The user |
User |
References
ls(1) man page
info coreutils (GNU Coreutils)
Section 13: Changing file attributes
