Unix File and Directory Permissions

 

Unix places restrictions on how users can use files, according to the characteristics of the user, the characteristics of the file, and the interaction between those 2 things. Characteristics? What characteristics?

Well, in the case of the user, we're merely talking about who or which user it is. His identity. In the case of files it's a little more complicated. Every file possesses a set of so-called "permissions." Directories also possess the same kind of permissions. The thing or "characteristic" about a file that plays a role in determining how users can use it are its permissions (also, the permissions of the directories in and under which it resides can get into the act). You have probably noticed permissions before, maybe without recognizing them, when using the long listing form of the ls command. Below is the long listing for the files in the home directory of user "joe" on a linux system. Notice the 10 leftmost characters in the listing for each file

[root@sputnik joe]# ls -l
total 52
drwxr-xr-x 4 joe joe 4096 Mar 13 06:05 Desktop/
-rw-r--r-- 1 david sales 524 Apr 8 21:30 adbudget
-rw-r--r-- 1 root root 30720 Apr 8 21:12 classifications.tar
-rw-r--r-- 1 joe sales 1620 Apr 8 21:29 mycalendar
-rw------- 1 joe joe 3302 Apr 8 21:29 mypaystubs
drwx------ 2 joe joe 4096 Mar 13 06:05 tmp/
[root@sputnik joe]#

The last 9 of those characters are the file's permissions, or permission set. So the permissions for adbudget are rw-r--r--, while those for mypaystubs are rw-------.

Every time you try to use the file, those permissions are applied to decide whether to let you do what you want or not. Actually, not all of them are applied. Only 3 of them. Either the 1st 3, the middle 3, or the last 3. So I need to explain these 9 "permissions," how and why they are divided into 3 sets of 3, within each set what each individual permission is for, and how each is applied.

But first, another characteristic of files that also appears in the ls long listing above. Every file is associated with some user. You know that users have to be formally "defined" and set up by the all-powerful user named "root." You may not know that root can also set up "groups" and then add users to them. By default (and perhaps confusingly), whenever a user is created a group of exactly the same name is created with the new user as its only member. More realistically, maybe the root user (system administrator) would create a group called "sales" and put into it all those users who belong to the sales department. In addition to a user, every file is also associated with some group.

In the long form of ls (see above) the 2nd column of each listed line reveals with which user the file being listed is associated while the 3rd column indicates its group. So adbudget is associated with user david and group sales; classifications.tar with user root and group root; and paystubs with user joe and group joe.

OK already, so how does this permissions thing work? Let's say you approach a file in order to read it (by issuing a command that needs to get at what's inside, such as cat). At that moment behind the scenes the system convenes a court to render a judgment whether or not to let you do it. The first thing the judge does is determine who you are. He compares that information with the user that's associated with the file. He wants to know if that user happens to be you yourself. If not, then he looks at the group associated with the file, figures out who its members are, and compares you with the membership. He wants to know if you're a member. By taking these 2 steps this he classifies you into one of 3 categories. Either you're the very user associated with the file, or you're not but you're part of its group, or else you're just a "casual stranger" as far as this file is concerned. In the technical jargon they say you are either "user," "group," or "other."

Now that he has found your relationship to the file, the judge picks out the corresponding subset of permissions. Of the 9 permissions, the first group of 3 applies to you if you are "user," the second if you are "group," and the third if you are "other." Whichever subset applies is all-controlling, and the other 2 subsets have no effect on your interaction with the file. Here's an example:

You can see the subdivision of the 9 permissions into groupings of 3.

What about the individual permission items within each grouping? Each one is either on or off. The first governs whether or not you will be able to read the file. The second, whether (separately) you can write to it. And the third (again, independent of the other two), if you are allowed to execute the file (which isn't always meaningful, for files such as text documents that aren't executable anyway for example). Representationally, a permission that's turned off is shown as a hyphen, and one that's turned on as a letter. Which letter? if it's the "read" permission, r; if the "write" permission, w; and if the "execute" permission, x.

Some examples. You are user david. You wish to "cat" (i.e., read) 3 files in joe's directory. They are adbudget, mycalendar, and mypaystubs. When you go to "cat adbudget," court is convened behind the scenes.

"What is the name of the appellant user?" the judge asks the bailiff.
"It's david, your honor," replies the bailiff.
"And for what file does user david submit his pleading?"
"For adbudget, your honor."
"I see. Tell me, what would be adbudget's user, bailiff?"
"david, sir."
"The self-same?"
"Yes, your honor."
"Then hand me adbudget's user permission set please."
"Herewith, sir." [ hands rw- to the judge ]
"Hrrmff. Read permission being explicitly granted I see [first permission is r, not hyphen], release the appellant to read adbudget forthwith."

david then sees the file contents on the screen. If  david wanted to write to adbudget, that too would be allowed but not for the same reason. The reason would be the presence of the w (not the r). And if he wanted to execute adbudget, the judge wouldn't let him. Why? Because there's a hyphen there in the 3rd position instead of an x. Note, in the case of reading, the reason david was allowed to do so was not simply that he is the "owner" of the file, but that there is an "r" in place for whether the owner can read that file. If there were a hyphen, it's entirely possible the owner would not be permitted to read "his own" file. Just being the "owner" is not enough.

If david wants to work on mycalendar, whose permissions are rw-r--r--, we can throw out the rw- (first permission subset) since this file is associated with joe, so the rw- applies to joe and nobody else. The set that applies for david will either be the second one, r--, if david happens to be a member of group "sales;" otherwise the third one, r--, if not. We don't know if he's in sales, but since the permission sets for both group and other happen to be identical, we know what david can and can't do. If he wants to read mycalendar, he can. But if he wants to write to it, or try to execute it, he can't.

And if he wishes to work with mypaystubs (rw------- joe joe), similarly the first permission set rw- does not apply since david is not joe. And david will get either the second or the third, depending if he's in the sales group or not. Whether he gets the second or third won't matter since both of those are the same. So either way what he's going to get is --- or off-off-off, meaning no reading, no writing, and no executing. (I guess Joe's paystub information is confidential.)

So, for files, the effects of the individual permissions on the affected user's ability to work with the file are:

r - read
 can open file
w - write
 can modify, overwrite, truncate file
x - execute
 can try to execute file (which may or may not turn out to itself be able to execute)

At the same time, directories have these same permissions, but with somewhat different effects. The user's interaction with a file are not only affected by the file's own permissions, but also by those of the directory containing the file (and the directory containing that directory...). For directories:

r - read
 can view contained files
w - write
 can change contained files (add, rename, remove)
x - execute
 can enter the directory (cd)
 can open contained files in directory or its subdirectories

So you might be unable to read a file, even though its permissions would allow it, if it resides in a directory that forbids it.

How can you change a file's permissions? There is a command for that. The command is "chmod" and whether or not you are allowed to apply it to a given file itself depends on your permissions for that file. Using chmod is a lesson for another day.