There are few things as confusing, frustrating, and aggravating for those who come to Linux from Windows as the whole notion of permissions. Based on my own personal experience, I would say as much as 25% of the problems I've had using Linux over the years have been permissions related. It's a subject your mother didn't teach you, and you didn't learn on the playgrounds. That's why we're going to get down and dirty with the CLI today: to learn about permissions on Linux, right here, right now.

What we want to concentrate on right now is the first bit, drwxr-xr-x. This string of characters lists the full permissions of the file or directory. It is also important to know the next two strings (in this case both are jlwallen) are the user and group associated with the file.

Let’s go back to the permissions string. The first character, d, means the listing is a directory. Now, instead of looking at the next portion of the string as a single group, think of it as three groups:

Linux systems have multiple users -- and a permissions system that lets each user share or protect their files. This unique system has some odd twists. For example, did you know that, to rename or remove a file, you need write permission for the directory that the file is in? A thorough understanding of permissions lets you make your system more secure, share data easily with other users, and protect files from accidental changes. Let's look into the basics -- and some dark corners -- of Linux filesystem permissions.

Ownerless files can be an indication that someone has gained access to your system. You should check regularly using the command # find / -nouser -o -nogroup. If you find any ownerless files, either delete them, or, if you know what they are and wish to keep them, assign them to an appropriate user and group. For example, assign myfile to the user foo and the group bar you would issue the command # chown foo.bar myfile

Pathnames can confuse users, but they’re actually simple when you see how they work. A pathname gives the location of an object (a file, a directory, a socket, etc.) in the filesystem. There are two kinds of pathname: absolute (or full) and relative:

Within UNIX, system calls have base permissions (sometimes referred to as "default permissions") with which to create new files and directories. For directories the base permissions are (octal) 777 (rwxrwxrwx), and for files they are 666 (rw-rw-rw). Before creating the file or directory, the base permissions are compared to a mask (the umask set by the umask command) that will "mask out" permission bits to determine the final permissions for the object being created. The calculation to determine the final permissions is to take the binary of the base permissions and perform a logical AND operation on the ones complement representation of the binary umask.

In GNU/Linux, file access is restricted. Users don't necessarily have the same rights when it comes to deleting, executing or even reading files. In fact, every file contain data such as its owner, its permissions and other information which defines exactly what can be done with it, and by whom.

As an SELinux administrator, one of the most frequent SELinux policy customizations you're likely to perform is adding permissions to coax the security engine into accepting an operation. Let's consider an actual situation based on Fedora Core 2's SELinux implementation and see how it's resolved. The procedure we'll follow isn't the only procedure or best procedure. Creating new policies typically entails a generous dollop of troubleshooting, which tends to be relatively unstructured. So rather than see our procedure as the universal norm, you should see it as merely an illustrative example.