Controlling File Access

Working groups, file permissions, file ownership, and compartment rules determine who can access a given file. The simplest of the file access rules are standard UNIX file permissions.

You can divide users into groups so that files owned by the group can be shared within the group and can be protected from outsiders.

The traditional UNIX file permissions are displayed using the ls command with the -l flag. The permissions indicate what kind of access (that is, the ability to read, write, and execute) is granted to the owner and groups on your system. Traditional UNIX file protections allow some control over who can access your files and directories, but they do not allow you to define access for individual users and groups beyond the owning user and the owning group. The following is a brief review of UNIX file permissions.

Each file and each directory has nine permissions associated with it. Files and directories have the following three types of permissions:

r (read)
w (write)
x (execute)

These three permissions occur for each of the following three classes of users:

u (user/owner)
g (group)
o (all others; also known as world)

The r permission allows users to view or print the file. The w permission allows users to write (modify) the file. The x permission allows users to execute (run) the file or to search directories.

Figure 6-1 shows the traditional permissions fields.

Figure 6-1 File and Directory Permission Fields

The user/owner of a file or directory is generally the person who created it. If you are the owner of a file, you can change the file permissions with the chmod command.

The group specifies the group to which the file belongs. If you are the owner of a file, you can change the group ID of the file with the chgrp command.

The meanings of the three types of permissions differ slightly between ordinary files and directories. See Table 6-1 for more information.

Table 6-1 Differences Between File and Directory Privileges

Permission	File	Directory
`r` (read)	Contents can be viewed or printed.	Contents can be read, but not searched. Normally r and x are used together.
`w` (write)	Contents can be changed or deleted.	Entries can be added or removed.
`x` (execute)	File can be used as a program.	Directory can be searched.

Setting File Access Permissions

The chmod command changes the type of access (read, write, and execute privileges) for the file's owner, group members, or all others. Only the owner of a file or a user with the appropriate privileges can change file access. See chmod(1).

By default, the initial set of read and write permissions for files and directories are determined by the creator's umask value. To change the default file permissions, use the umask command. See umask(1).

Each bit that is set in the file mode creation mask causes the corresponding permission bit in the file mode to be cleared (disabled). Conversely, bits that are clear in the mask allow the corresponding file mode bits to be enabled in newly created files.

For example, a umask of octal 022 creates a mask of u=rwx, g=rx, o=rx, which disables group and other write permissions.

Setting File Ownership

The chown command changes file ownership. To change the owner, you must own the file or have the appropriate privileges.

The chgrp command changes file group ownership. To change the group, you must own the file or have the appropriate privileges.

For more information, see chown(1) and chgrp(1).

Protecting Directories

Normally, if a directory is writable either through standard permissions or through ACLs, anyone can remove the files in the directory, regardless of the permissions on the files themselves. To protect against unwanted file deletions in a directory:

Remove write permissions for directories that should not have them.
This is particularly effective for users' private directories. The following command allows others to read and search the mydir directory, but only the owner can delete files from it:
# chmod 755 mydir
See chmod(1) and chmod(2).
Set the sticky bit on the directory.
The sticky bit is a special bit in the mode of every file. Setting the sticky bit prevents users from removing other users' files from that directory. Setting the sticky bit for a directory allows only the owner of the file, the owner of the directory, or a user with the appropriate privileges to delete or to rename the files.
This is effective for temporary or project directories (such as /tmp and /var/tmp) that must be accessible to many authorized users. The following command allows anyone to create, read, and write files in /mfgproj, but only the file owner, the directory owner, or a user with the appropriate privileges can delete files:
# chmod a+rwxt /mfgproj
Setting the sticky bit is important for directories that are used for temporary files. In the event that a temporary directory is not set to sticky, an attacker may alter the expected behavior of user programs by waiting for a temporary file to be created and then deleting and recreating a new file with modified content, but the same name. In most cases, the application is unaware of the change and may unintentionally perform malicious acts on behalf of the attacker.

Protecting Files Related to User Accounts

Follow these guidelines to protect files related to user accounts:

A home directory should not be writable by anyone except for the owner. Otherwise, any user can add and remove files from the directory.
The .profile, .kshrc, .login, and .cshrc files for each user should not be writable by anyone other than the account owner.
A user's .rhosts file should not be readable or writable by anybody other than the owner. This precaution prevents users from guessing what other accounts you have, and prevents anyone from editing your .rhosts file to gain access to those systems. For more information, see hosts.equiv(4).
Do not use a .netrc file, because it bypasses login authentication for remote login and even contains the user's unencrypted password. If used, .netrc must not be readable or writable by anyone other than its owner. For more information, see netrc(4).

Locating and Correcting File Corruption Using fsck

The following problems can indicate a corrupt file system:

A file contains incorrect data (garbage).
A file has been truncated or is missing data.
Files disappear or change locations unexpectedly.
Error messages appear on a user's terminal, the system console, or in the system log.
You are not able to change directories or list files.
The system fails to reboot.

If you or other users cannot readily identify problems with the file system, use the fsck command to check the file system. The fsck command is the primary tool for finding and correcting file system inconsistencies. The fsck command examines the file system listed in /etc/fstab.

The fsck utility is not capable of detecting file corruption. If fsck does not find any errors, the problem is likely not a corrupted file system. That is, the file system is usable, even if the underlying data is lost or corrupted. Look for one or more of these other file problems:

A user, program, or application deleted, overwrote, moved, or truncated the file or files.
The file system associated with a particular directory when the file was created might not be mounted to that directory.
A file or files were placed in a directory that now has a file system mounted to it. The files still exist but are not accessible. Unmount the file system to access the files.
The file protection or ownership is preventing access. Use the chmod or chown command to change file permissions.

Controlling File Access

Technical documentation

» Table of Contents

» Glossary

» Index

Setting File Access Permissions

Setting File Ownership

Protecting Directories

Protecting Files Related to User Accounts

Locating and Correcting File Corruption Using fsck