The standard Unix file permissions system can be used to enhance basic security. Chad Perrin explains the basics of file-level security management in Unix-type systems.
The word Unix is archetypal. It refers not to a single operating system, but to a whole family of systems descended from the original AT&T Unix developed by Ken Thompson and Dennis Ritchie, with later help from Brian Kernighan. Since then, an actual, official IEEE standard for expected Unix operating system capabilities and characteristics, called the POSIX Standard, was developed. The UNIX trademark is used to label systems that conform to the Single UNIX Specification, whose current version (SUS version 3) is identical with the POSIX:2001 standard.
Part of that standard, and something you can be sure to find in any OS that pretends to being Unix-like -- such as any of the various BSD Unix systems or Linux distributions -- is the Unix file permissions system. This system provides three categories of entities, each of which can be granted or denied any of three specific permissions.
Each file and directory (a special type of file) has an "owner." This is the user account that has primary power over the file, allowing it to do things like change the file's permissions. The owner is expressed as a user account such as
rootor your personal user account, or even some "user" account automatically created for the use of a piece of software you have installed. Normally, the owner of a file is the account used to create the file, though files can be reassigned to a different owner later on using the
In addition to the owner, each file has a group account associated with it. This group, like the user account that is the file's owner, has its own set of access permissions to the file. When creating a file, the group is set to the default group of the user account used to create the file, though files can be reassigned to a different group later on using the
chgrpcommand. For instance, for the
rootaccount, this usually means that the file's group owner is the
wheelgroup on BSD Unix systems.
- World The last permissions category covers "everyone else" -- any accounts that are not the owner or a member of the account group that is the file's group owner.
The permissions themselves have binary numerical values:
The binary number 100 grants read permissions. This means that whatever entity category has this permission for the file can read its contents. An account needs to have read permission to a directory to be able to list its contents. Binary 100 is decimal 4, and the "read" permission is often abbreviated
The binary number 10 grants write permissions. This means that whatever entity category has this permission for the file can overwrite or change the file, or even delete it. An account needs to have write permission to a directory to be able to make changes to the directory contents, such as creating new files there. Binary 10 is decimal 2, and the "write" permission is often abbreviated
The binary number 1 grants execute permissions. This means that whatever entity category has this permission for the file can execute that file, as in the case of being able to run a program. If no entity category has execute permissions for the file, it is considered nothing but an inert piece of data on the hard drive. An account needs to have execute permission to a directory to be able to enter the directory for any reason, including listing its contents, because even listing the contents of a directory from outside the directory requires the user account trying to perform that action to enter the directory and "look around". Binary 1 is decimal 1, and the "execute" permission is often abbreviated
These numbers can be combined to create a set of permissions for a given user entity. For instance, 110 combines 100 and 10, thus giving the entity category with 110 permissions for that file read and write access, but not execute access. Just as
100 + 10 = 110,
4 + 2 = 6, which means that the binary representation 110 here is identical to a decimal representation of 6.
Listing and changing
To see a file's permissions settings, the
-l option for the
ls command provides information that includes permissions. Running this command on the
/etc/periodic directory of a default FreeBSD system might look like this:
> ls -l /etc/periodic
drwxr-xr-x 2 root wheel 1024 Sep 7 09:10 daily
drwxr-xr-x 2 root wheel 512 Sep 7 09:10 monthly
drwxr-xr-x 2 root wheel 512 Sep 7 09:10 security
drwxr-xr-x 2 root wheel 512 Sep 7 09:10 weekly
d at the beginning of each line indicates the file is a directory. The rest of the permissions block thereafter are broken up into three-character groups, corresponding in order to owner's read, write, and execute; group's read, write, and execute; and world's read, write, and execute. A dash in any position indicates that the relevant entity category does not have that permission. Thus, for the directories within
/etc/periodic, the owner has 111/7/rwx permissions, or "read, write, execute", while the group and world permissions are both 101/5/r-x, or "read, execute".
The columns showing
wheel are the owner and group assignments for those files.
Let's say you have a file,
tmp.txt, and you want to change its permissions. For the sake of the example, we will say its permissions start out looking like this:
> ls -l tmp.txt
-rw-r--r-- 1 jon doe 0 Nov 12 15:30 tmp.txt
As already mentioned, owner and group assignment can be changed using the
chgrp commands. In each case, the form of the command is
command entity filename. Thus, to grant ownership of file
tmp.txt to user account
root, you would enter this command:
> chown root tmp.txt
To assign file
tmp.txt to group
wheel, you would enter this command:
> chgrp wheel tmp.txt
You can change the permissions for each of the three entity categories using the
chmod, or "change mode", command. The syntax for
chmod's most basic usage is similar to that of the
chgrp commands, but uses decimal permission values by default rather than account and group names, so that if you wanted to change the permissions of file
tmp.txt to 111/7/rwx for the owner, 101/5/r-x for the group, and 000/0/--- (no permissions at all) for the world, you could use this command:
> chmod 750 tmp.txt
Checking permissions after these changes would look like this:
> ls -l tmp.txt
-rwxr-x--- 1 root wheel 0 Nov 12 15:30 tmp.txt
Note that, to make any changes, you have to be logged in as an account that has the necessary system privileges to be able to affect not only the file, but any user accounts or groups that are also affected. As such, you should not be able to assign
tmp.txt to the
root user without being logged in as
Additional options are available for managing permissions and file ownership using these commands. Check each utility's manpage for more information.
File-level security management
If you use a Unix OS, or Unix-like OS, you should -- as a bare minimum -- understand this most basic form of file-level security management. Failing to understand file permission management might cause problems one day. The fundamental key to basic file-level security on a Unix system is to keep file permissions as restrictive as possible without stopping the system from doing what it needs to do, and without preventing yourself from accessing the files the way you need to access them.
For the most part, file permissions outside of user account home directories -- such as
/usr/home/jon/ in the case of the above hypothetical
jon account or
/root/ in the case of the
root account on a FreeBSD system, or
/root/ respectively on a typical Linux-based system -- should be left to defaults unless you know exactly what you are doing.
Most data files in a user account's home directory, such as text files, word processor files, and so on, should have 110/6/rw- permissions for that account and 000/0/--- for group and world permissions, while most subdirectories within that home directory should have 111/7/rwx for the owner and 000/0/--- for the group and world permissions, especially if you are concerned about privacy protection against other accounts or malicious security crackers that may compromise or create other accounts on the system.
Learn how to use Unix file permissions to best effect, and you will know the first thing to know about Unix security. Without secure use of file permissions, the strong privilege separation of a Unix operating system that provides it such a significant security advantage over many other OSes can be undermined.