A Review of File and Directory Permissions

In the Linux/Unix world, access permission to a file or directory is determined by whether you are the owner of the file or directory, a member of a specific group assigned, or none of the above (otherwise known as "other" or "world"). In other words, there are three trustee assignments (using a NetWare term) possible for each file and directory.

NOTE

A directory is just a special file that contains files and other directories; therefore, for the following discussion, the term file is used to refer to both file and directory unless otherwise specified.

The command ls -l displays, among other information, the file type and permission settings of a file. Figure 6.1 shows an example of such a listing and identifies the permission applicability. As you can see, each permission setting consists of three fields (a triplet) and is displayed for each of the three trustees. The possible permission value of each field is listed in Table 6.1; the permissions are always in the same order: read, write, and execute for the user, the group, and the others (a.k.a. the world).

Figure 6.1. File type and permissions.

Table 6.1. Symbolic Permission Values

PERMISSION	SYMBOL	DESCRIPTION
Read	r	On a file, this means the file is readable. On a directory, it means the contents of the directory may be accessed. It is located in the first position of a triplet.
Write	w	On a file, this means the file may be modified. On a directory, it means that files in the directory may be created, renamed, or deleted. It is located in the second position of a triplet.
Execute	x	On a file, this means the file is executable. On a directory, it means that the directory may be traversed and searched for a file (such as using ls directory). It is located in the third position of a triplet.
Sticky	t	On a directory, the sticky bit means users other than the owner or root cannot delete or rename (but can modify) files in this directory, even if they have write permission to the files and the directory. This permission applies only to "others" and is located in the third position of a triplet. On a file, the symbol appears as T and has no effect. A lowercase t means both the sticky and the execute bits are set; an uppercase T means the sticky bit is set, but execute is not.
Set UID (SUID) or Set GID (SGID)	s	Applicable only to the owner or group permission triplet. When found in a file's owner triplet, it means that, when executed, this file will execute with the UID of the owner of the file instead of the UID of the user executing the program; it has no effect if set on the owner triplet of a directory. If set in the group triplet of a file, the executed file will assume the GID of the group owner instead of the primary GID of the user executing the program. When set on the group triplet of a directory, all new files and subdirectories will inherit the same GID as the directory itselfdirectories will also inherit the SGID bitand not the GID of the user who created them; existing files and subdirectories are left unchanged. A lowercase s means the SUID or SGID bit is on, and the corresponding user or group execution bit is also on; an uppercase S means the SUID bit is set, but the corresponding execution bit is not set.This setting is located in the third position of a triplet.
No permission	-	If this symbol appears in any position in the permission triplet, it means that no permission is assigned in that position.

NOTE

The sticky and SUID/SGID permission bits are further discussed in the "Special File Permissions" section later in this chapter.

The ls listing in Figure 6.1 shows the following information, from left to right:

• The character in the first column reflects the file type and can be one of the following:

  -, as shown in the example, means this is a regular file.

  b is a block (buffered) special file (such as a tape drive or floppy drivefor example, /dev/fd0).

  c or u is a character-oriented (unbuffered) special file (such as a terminal devicefor example, /dev/ttyp0).

  d means it's a directory.

  l is for a symbolic link.

  p is a special FIFO (first in, first out) file (such as a named pipe).

  s is a socket file that provides interprocess networking.

• The first triplet of permission settings (rw-) indicates the file owner can read and write to the file but not execute it (as a binary program or a shell script).

• The second triplet (r--) indicates the members of the file's group can only read the file.

• The third triplet (r--) indicates everyone else (often referred to as world, as in "rest of the world") can only read the file.

NOTE

If a + is displayed after the "others" permissions (such as r--+), it means an access control list (ACL) is assigned to the file. See the "Extended File Attributes" section later in this chapter for details.

• The number of (hard) links to the file; only one link in this example.

• The file owner is user root.

• The file group owner is the root group.

• File size in bytes (13 bytes in this case).

• The modification time.

• Name of the file, myFile.

NOTE

For a shell to execute a file containing shell script commands, the file must have the proper x permission bits set. For instance, for both the file and group owners to be able to run the script file, the x permission must be set on the corresponding triplets. Similarly, if a binary executable, such as the vi editor, is not set with the x permission, you cannot run it.

On the other hand, without the execute bit set, you can still execute the script by typing sh filename for a shell script, perl filename for a Perl script, and so on. The difference is that the running shell doesn't recognize the script as being executable, but the script interpreter (such as /usr/bin/perl) will happily parse the content of the script file and execute the commands, even if the x bit is not set.

FILES WITH NO OWNER OR GROUP

Ownerless files can be an indication that someone has gained access to your systemcreated a backdoor user, modified or created some files, and then removed this backdoor user without completely covering his or her tracks. Sometimes these files may just be files created by package installations. You should check regularly for such files using the find command:

 Athena:/home/admin # find / -nouser -o -nogroup 

If you detect any ownerless files, either delete them, or, if you know what they are and want to keep them, assign them to an appropriate user and group using chown.

Bear in mind that the find command can take awhile to run because it needs to check every single file on your system. You may consider using a combination of the -path and -prune options to limit the search scope. For example, the following find command will skip checking files and directories in /home/shared directories and below:

[View full width]
 Athena:/home/admin # find / -path '/home/shared' -prune -nouser  -o -nogroup 

The meaning of the rwx permissions to files is rather straightforward. However, it is not so obvious when it comes to applying them to directories. The read (r) permission bit on a directory allows you to access its files using ls or similar tools. The reason is that a directory is a special type of file that contains, among other things, the names of files that are stored "in" the directory. So, being able to read a directory lets you access the files stored in it.

In the same way, write (w) permission to a directory lets you modify the directory's contentssuch as to change the names of the files stored in that directory. To add, remove, or rename a file, you need write permission on the directory that contains the file's name. If a directory is write-protected, the list of entries in that directory cannot be changedaccidentally or on purpose.

The execute (x) permission on a directory lets you search for entries in that directory. Even if you have read permission on a directory (which lets you access files that are in it), you can't search for any of its entries unless you also have the execute permission. This may sound a little confusing, but the example shown in Listing 6.1 demonstrates this concept succinctly.

Listing 6.1. Effect of the Execute Permission Bit on a Directory

 # md test # #just to make sure only the owner has rights # chmod go-rwx test # ls -ld test drwx------  2 peter users 48 2005-01-19 01:21 test # echo "This is a permission test" > test/file.txt # ls -l test total 4 -rw-r--r--  1 peter users 26 2005-01-19 01:21 file.txt # #remove user's execute bit # chmod u-x test # ls -ld test drw-------  2 peter users 72 2005-01-19 01:21 test # #Hey, can't see directory listing without 'x'! # ls -l test /bin/ls: test/file.txt: Permission denied total 0 # #does tell me filename but wouldn't give file info! # ls -l test/file.txt /bin/ls: test/file.txt: Permission denied # #and can't read file even I have 'r' to the file itself # cat test/file.txt cat: test/file.txt: Permission denied # #put 'x' back on the directory # chmod u+x test # #can see the file now # ls -l test/file.txt -rw-r--r--  1 peter users 26 2005-01-19 01:21 test/file.txt # #What if no 'r' to directory, but have 'x'? # chmod u-r test # ls -ld test d-wx------  2 peter users 72 2005-01-19 01:21 test # #can't do "wildcard" search without 'r' # ls test /bin/ls: test: Permission denied # #but okay if I know the exact filename! # ls -l test/file.txt -rw-r--r--  1 peter users 26 2005-01-19 01:21 test/file.txt # more test/file.txt This is a permission test 

Without execute permission on a directory, you can't access any of its subdirectories. That means you can't access a directory unless you also have execute permission on all its parent directories, all the way up to the root directory!

NOTE

The root user is not affected by any of the rwx permission restrictions.

Some graphical applications may not handle Linux permissions very well. Because applications such as Nautilus usually show dialog boxes with icons for the files in a directory, they have to be able to "execute" the directory. So, in the example shown in Listing 6.1, if you try to reach a subdirectory under test by clicking through permission.test, you will not be able to. Furthermore, because Nautilus cannot determine the correct file types, subdirectories are displayed (in most cases) using document icons.

Changing Permissions

Although it is a lot easier to change the permission settings using a graphical interface, such as Nautilus (see Figure 6.2), knowing how to perform the task "the hard way" leads to your better understanding the information presented in a GUI dialog box, but the reverse does not hold true. Therefore, to be an effective administrator or power user, you should have an understanding of what takes place "under the hood."

Figure 6.2. Changing file permissions using Nautilus.

Each of the three sets of permissions is stored as a three-bit digit, and each bit corresponds to one of the read, write, and execute permissions. For easy use with commands, both access permissions and user groups have a code, as shown in Tables 6.2 and 6.3, respectively.

Table 6.2. Access Mode Codes

TEXTUAL PERMISSION SYMBOL	NUMERIC VALUE	DESCRIPTION
-	0	No permission granted
r	4	Read access
w	2	Write access
x	1	Execute access

Table 6.3. User Group Codes

CODE	DESCRIPTION
u	User permission triplet
g	Group permission triplet
o	Others, or world, permission triplet
a	A shortcut for all three triplets

The chmod utility is used to change the access mode of a file or a directory. You can use it with numeric code or alpha code valueswhatever works best for you. The general command syntax is

 chmod access_mode_options target_file_or_directory 

NOTE

Within the Linux/Unix world, the term "to chmod" has become an almost acceptable English verb, meaning the changing of the access mode.

The access_mode_options uses the +, -, and = operators to add, remove, or assign permissions to a given group. Combinations separated by commas are allowed. The following example grants the owner of test full access while removing all accesses from the group owner and the world:

 Athena:/home/admin/demo # chmod u=rwx,go-rwx test 

NOTE

If you specify more than one mode option, as is in the preceding example, ensure there are no spaces before or after the comma. For example, if you used chmod u=rwx, go-rwx test, chmod considers what comes after the space (go-rwx test) as filenames and results in a "No such file or directory" error when trying to access go-rwx.

If a file's owner currently has the rw permission, for example, chmod u=rx will overwrite the current access rights with the new ones, while chmod u+rx will add the execute permission (because the read permission already has been granted).

When you use chmod with numeric arguments, the values for each granted access right have to be counted together per group. Thus, you get a three-digit number, which is the symbolic value for the settings chmod has to make. For example, for rw- permission, the corresponding numeric value (see Table 6.2) is (r=4) + (w=2) = 6. Therefore, the numeric value for rw-rw-rw- is 666. Table 6.4 lists the most commonly used numeric permission combinations to protect files and directories.

Table 6.4. Common chmod Settings

COMMAND	TEXTUAL VALUE	MEANING
chmod 400 file	r-- --- ---	To protect a private file from being accidentally deleted or modified by the owner.
chmod 500 directory	r-x --- ---	To protect the owner from accidentally removing, renaming, or moving files from this private directory.
chmod 600 file	rw- --- ---	A file that can only be accessed and modified by the owner. A common setting for private files.
chmod 644 file	rw- r-- r--	A publicly readable file that can only be modified by the owner.
chmod 660 file	rw- rw- ---	The owner and members of the group owner have access, but not the world. A common setting for shared files.
chmod 700 file	rwx --- ---	Only the owner has full access to the file, and the file can be executed (such as a shell script). A common setting for a private shell script or program.
chmod 701 directory	rwx --- --x	Generally set on the "outgoing" directory on an FTP server where users can download a file only if they know the exact filename.
chmod 703 directory	rwx --- -wx	Generally set on the "incoming" directory on an FTP server where users can upload to files but cannot browse for or download existing files.
chmod 755 directory	rwx r-x r-x	For files in a directory that should be readable and executable by others, but only changeable by the owner.
chmod 775 file	rwx rwx r-x	Standard file-sharing setting for a group.
chmod 777 file	rwx rwx rwx	Everybody can do everything to this file.

NOTE

There is actually a fourth digit, which precedes the first three and sets special access modes, namely the sticky bits and the SUID/SGID bits. These settings are further discussed in the "Special File Permissions" section later in this chapter. To simplify discussion here, you can consider that leading digit to be zero and can omit it when specifying values for chmod.

CAUTION

If you enter a number with fewer than four digits as an argument to chmod, omitted characters are replaced with zeros starting from the left. In other words, chmod 77 is the same as chmod 0077.

Changing User and Group Ownership

If the wrong user or group or no owners own a file or directory, the error can be repaired using the chown (change owner) and chgrp (change group) commands. Changing file ownership is a frequent system administrative task in environments where files need to be shared within a group.

The chown command can be applied to change both user and group ownership of a file/directory, while chgrp changes only the group ownership. Of course, the system will check if the user issuing one of these commands has sufficient permissions on the file(s) to be changed. The general syntax of chown is

 chown [options] newuser[:newgroup] file 

Instead of names, numeric UIDs/GIDs may be used instead.

If a colon is used after the username and no group name is given, group ownership will be changed to the primary group of the (administrative) user issuing the command. If no username is provided but a :newgroup is specified, chown changes the group owner, performing the same function as chgrp, whose general syntax is

 chgrp [options] newgroup file 

NOTE

With SLES, instead of a colon in the chown/chgrp commands, you can use a period instead. However, it is a more standard convention to use a colon.

Both chown and chgrp can be used to change ownership recursively, using the -R option. In that case, all underlying files and subdirectories of a given directory will belong to the given user and/or group.

TIP

You can use the --from=user[:group] option with chown so that only those files and directories whose current owner and/or group match those specified will be assigned a new user and/or group owner. This capability is useful in reassigning ownership if the files and directories are scattered across a number of branches of a filesystem.

Security Considerations

Incorrect file permissions may allow some users to read or modify files that they don't supposedly have access to. The following are two incorrect file permission exploits a hacker will take advantage of: world-accessible (read and/or write) files and group-owned files.

Many system-related files are stored in /etc. Some are world-readable, such as the xinetd configuration files. However, some /etc files should not be world-readable. For example, the /etc/shadow file contains hashed user passwords that should be restricted from world access. Anyone with access to this file may brute-force crack passwords using tools such as John the Ripper. You can easily locate world-readable files using the following find command:

 $ find / -type f -perm -4 -print 2> /dev/null 

It is not uncommon for an administrator to make a backup copy of an important system file (perhaps /etc/shadow) before making modifications or testing a procedure. Perhaps due to an oversight on the umask setting (discussed in the "Default Access Permissions" section later in this chapter), the newly created backup file will be world-readable, even if the original file was not! And when that happens to something sensitive like the shadow password file, your system could be compromised.

World-writable files or directories can result in Denial of Service (DoS) attacks or a Trojan horse installation. For instance, it is fairly easily to fill up a filesystem with data when a world-writable file or directory is found. Similarly, a world-writable binary can easily be turned into a Trojan horse; a world-writable xinetd/inetd configuration file can become the source of a backdoor. For example, if /etc/xinetd.d or one of its configuration files (such as vnc) is world-writable, someone could add or modify an existing service and launch an alternate binary. As is the case with world-readable files, you can easily locate world-writable files using the following find command:

 $ find / -type f -perm -2 -print 2> /dev/null 

SERVICES BACKDOOR

Say your /etc/xinetd.d/telnet file is writable by someone other than root. Some malicious user or hacker may come across it and make two small modifications: change /usr/sbin/in.telnetd to /bin/bash and enable it to service if it is disabled. Now, when you connect via Telnet, it drops you into a "root shell" (because the service runs as root) instantly! No username prompt; no password prompt. The catch here is that you can't run any interactive program, such as vi, and each command you send must be appended with a semicolon (;) or ampersand (&). (For each successful command executed, you will see a "command not found" message displayed by the shell.)

With Linux being open source software, just about all its components are freely available in source code format. A hacker would just need to modify some SUID program, such as ping or passwd, and wait for it to spawn a hidden root SUID shell when executed.

As an administrator, you should check frequently to see whether any previously disabled service is suddenly active and review the contents of the configuration files for unfamiliar changes. The popular targets are services that use privileged ports (ports lower than 1024) because they generally run as root. Any service that runs as root, however, is a potential target.

Often, an application's configuration file is set to be group-readable and-writable. At the same time, some applications store passwords in cleartext in their configuration files. Furthermore, human nature suggests that the probability of someone (such as the system administrator) using the same password for server login and application login is high. Therefore, if a hacker gains access to the unprivileged account named eric, there is a chance that the hacker can locate the root password in one of the group-owned files that Eric has access to.

First, after the hacker logs in using account eric, he can find out the groups Eric belongs to by using the id command:

 $ id uid=1001(eric) gid=100(users) groups=100(users),201(web) 

After noticing Eric belongs to the group named web, the hacker can then use the find command to locate all files owned by that group:

 $ find / -group web -print 2> /dev/null /projects/web/README /projects/web/passwd.txt /projects/web/index.html /projects/web/passwd.txt.backup 

And the two passwd.* files may prove interesting!

From the information in the password files, the hacker may gain access to other accounts, which may in turn lead to more passwords. As the cycle goes on, the hacker may eventually gains root access. Therefore, it is very important that good security procedures be devised and enforced. (Refer to the "Corporate Security Policies" section in Chapter 11, "Network Security Concepts," for more information.)