File permissions

The rights a user has to do things to files or objects. In *NIX there are 3 basic permissions available, read, write, and execute. A file permissions may look something like:

-rwxr-x--x

The first character is used for special permissions (ex: link, directory, sticky-bit). The next three are your permissions (rwx), characters 5, 6, and 7 are group permissions, and 8, 9, and 10 are for everyone else. Other Operating Systems / Network Operating Systems have other rights.

In an Unix filesystem, every file and directory have a set of permissions that control the kind of things that a user can do to a file or directory.

There are three actions that you can control. Reading, writing and executing. For directories this actions means; Reading, listing the contents. Writing, creating or removing files inside the directory. And executing means accessing the files inside the directory.

In Unix there are users and groups, and the file systems tracks which user and group a file belongs to. You can assing diferent permissions to the owner of the file, to the people in the file's group and to everyone else.

There are also another three "special" permissions; setuid, setgid and the sticky bit (nice name).

Setuid works only on executable files. If a program has the setuid set, then the program runs on behalf and with the personality of the owner of the program not matter which user really fired the program.

Setgid is similar to setuid on files, but uses the permissions of the program's group instead of the program's owner. Setgid also works on directories, inside a directory with the setgid set all files created will have the same group has the directory insted of the creator's group.

The sticky bit works for directories, and it's mean for shared directories. Usually any user with writing permissions for a directory can erase any file in that directory despite that him may not own those files, in a directory with the sticky bit set this is forbiden.

Initially the sticky bit has used to mark executable files asking the kernel to mantain the program in RAM even after it's execution. It was useful for often used utilities. Modern paging and swaping memory technics do this in a diferent and better fashion (paging on demand), so this bit became useless for a while.

The set of permissions of a particular file is also called it's "access mode".

There are two ways to express the permissions the symbolic form or by a octal number.

The symbolic form looks like the first column of ls -l. There are 10 chars in there but the first one is not a permission it's the type of the file. Next comes three sets of three chars. Those are the permissions sets for the owner, the group and everybody else.

The first char it's the read permission it can be "r" when set, "-" when not set.

The second is the write permission "w" when set, "-" when not set.

And the last one is the execute permission "x" when set, "-" when not set. In the first set (the owner set) it looks like "s" when both execute and setuid are set, or "S" when only the setuid is set without the execute permission (useless). On the second set (the group set) it looks the same except that we are talking about setgid insted of setuid. And in the last set (the everybody else set) it looks like "t" when both execute and the sticky bit are set or "T" when only the sticky bit is set.

But I think that the octal form is nicer, see;

We have three kinds of permissions let's assing them a power of 2 value to each, read is 4, write is 2, and execute is 1. The sum of this values is 7 which falls nicelly within an octal digit.

7 means all permissions.
6 means can read and write (usefull for files)
5 means read and execute (usefull for programs and do-not-store-your-trash-here directories),
4 is the obvious you can read this file but don't change it.
3 is sort of silly.
2 it may seem stupid not to be able to see a file which you may write, but you can set up funny things like setting write only permissions for everybody and read permissions only for the owner. All the people can append their must kinky secrets to a file. Nobody can read the secrets of the other people but the owner of the file (Mrs.Counselor Hart let's say) can read and advice everybody secrets.
1 it's really unuseful, you can't run a program that you can't read. It may be used to mean; "Yup, this is the killer application I just wrote, but you can't run it just yet, keep pleading me in humiliation while me ego is fat enough).

The special permissions, in a similar fashion, are 4 for setuid, 2 for setgid, and 1 for the sitcky bit (man, I like that name!).

So we just need one octal digit for the special permissions plus 3 octal digits for the three sets. (Nifty, huh??)

You may think that it's strange that all your symbolic links have all the permissions set. You may even be scared to note that no matter how many times you change them, all the permissions stay set. But that's ok, symbolic links permissions are never looked at, the permissions of the file pointed to are used instead. In fact chmod changes the real file permissions instead of the link's ones.

While the earlier writeups in this node have dealt with file permissions under Unix, Windows NT also supports assigning file permissions. File permissions under NT, however, work quite differently than under Unix, so hopefully I will be able to illustrate some of the differences below.

To start out, the basic permissions under NT are read, write, read/execute, modify and full control. Read and write permissions are similar to their counterparts on Unix systems. The read/execute permission gives the user the same access that the basic read permission does, but in addition allows them to execute the file. The modify permission gives the same rights as the read, write and read/execute permissions, but in addition allows the user to delete the file. The full control permission includes all the rights of the previous permission settings, but in addition allows the user to take ownership of the file and change the permissions. Unlike Unix, where only the owner and root can change file permissions, under NT, anyone with the full control permission can change the permissions, and take ownership of the file, including guests and anonymous connections.

Permissions under NT are only available with the NTFS file system, not with FAT or FAT32. By default, when an NTFS volume is formatted, the full control permission is assigned to the everyone group. In other words, your newly formatted volume has no security whatsoever. I leave it as an exercise to the reader to decide what their next action should be.

The last major difference between NT and Unix permissions is deny takes precedence over allow. Perhaps an example is in order. Assume you are a member of the administrators group under NT. You set the permissions for a file so that the administrators group has full control, yet the everyone group is denied all permissions. You then notice that you can’t access the file. This is because although you as a member of the administrators group have full control, the everyone group (of which the administrators group is a member) has no control, and that takes precedence. The solution is to not give the everyone group any permissions, allow or deny. Windows will then deny the everyone group access, but still allow the administrators group to access the file.

There are many other nuances to NT file permissions, but hopefully this writeup gives you enough basics so that you can all go out and set up nice and relatively secure Windows NT systems.

A subtle point often overlooked with standard Unix file permissions is this:

You Can Revoke Priviliges With Group Permission

The permissions on a file are: user, group, other. But only one of these bits will ever be checked for a particular action. If the user is the owner of the file, the user bit is checked. If the user is a member of the file's group and not the owner of the file, the group bit is checked. If the user is neither owner nor a member of the file's group, only then will the other bit be checked.

Here is a useful example. Imagine a system with a powerful, potentially dangerous program called power. Most users on the system are trusted to run power, but a new user outsider, who is not trusted, must be added to the system. Without changing any of the existing users or their groups, the system administrator can ensure power is safe. The admin adds a new group called untrusted and makes outsider a member of this group. Then the permissions and uid/gid of power are changed to:
-rwx---r-x root untrusted power
(In other words, power has a gid of untrusted and permissions of 0705). When outsider tries to execute power, only the group bit is checked, and it is not set -- so access is denied. The other bit is never checked.

Of course, this still isn't nearly as flexible as access control lists and in practice programs like sudo are better.