Who Was That Masked User?

Every time you create a file, you are submitted to a default set of permissions. Go ahead. Create a blank file using the touch command. I am going to call my blank file "fish."

 [mgagne@testsys tmp]$ touch fish 

Now have a look at its permissions by doing an ls l:

 [mgagne@testsys tmp]$ ls -l total 0 -rw-rw-r--    1 mgagne   mgagne          0 Nov  5 11:57 fish 

Without doing anything whatsoever, your file has read and write permissions for both the user and the group, and read permission for everybody else. This happens because you have a default file-creation mask of 002. You can discover this using the umask command:

 [mgagne@testsys tmp]$ umask 002 

The 2 is subtracted from the possible set of permissions, rwx (or 7). 7 0 remains 7, while 7 2 is 5. But wait 5 stands for r-x, or read and execute. How is it that the file only shows a read bit set? That's because newly created files are not set executable. At best, they provide read and write permissions for everyone. Another way to display this information is by using the -S flag. Instead of the numeric output, you'll get a symbolic mask displayed.

 [mgagne@testsys tmp]$ umask -S u=rwx,g=rwx,o=rx 

If you have an application that requires you to provide a default set of permissions for all the files you create, change umask to reflect that inside your scripts. As an example, let's pretend that your program or script created text files that you wanted everyone to be able to read (444). Because the execute bit won't be a factor anyway, if you mask out the write bit using a 2 all around, then everybody will have read permission. Set your umask to 222, create another file (called "duck" this time), and then do an ls l to check things out:

 [mgagne@testsys tmp]$ umask 222 [mgagne@testsys tmp]$ touch duck [mgagne@testsys tmp]$ ls -l total 0 -r--r--r--    1 mgagne   mgagne          0 Nov  5 12:58 duck 

The setuid Bit

Aside from those three permission bits (read, write, and execute), there is one other very important one: the s bit, sometimes referred to as the setuid or setgid bit, depending on its position.

The reasoning behind this particular bit is as follows. Sometimes you want a program to act as though you are logged in as a different user. For example, you may want a certain program to run as the root user. This would be a program that you want a nonadministrative user to run, but (for whatever reason) this program needs to read or write files that are exclusively root's. The sendmail program is a perfect example of that. The program needs to access privileged functions in order to do its work, but you want regular (nonroot) users to be able to send mail as well.

The setuid bit is a variation on the "execute" bit. In order to make the hypothetical program, ftl_travel, executable by anyone, but with root's privileges, you change its permissions as follows:

 chmod u+s ftl_travel 

The next step, as you might guess, is to combine full permissions and the setuid bit. Start by thinking of the setuid and setgid bits as another triplet of permissions. Just as you could reference r, w, and x as 4, 2, and 1, so can you reference setuid as 4, setgid as 2, and other (which you don't worry about).

So, using a nice, complicated example, let's make that command so that it has read, write, and execute permissions for the owner, read and execute permissions for the group, and no permissions for anyone else. To those with execute permission, though, you want to have it setuid. You could also represent that command either symbolically or in a numerical way:

 chmod u=rwxs,g=rx,o= ftl_travel chmod 4750 ftl_travel 

The 4 in the front position represents the setuid bit. If you want to make the program setgid instead, you can change that to 2. And, yes, if you want the executable to maintain both the owner's permissions and that of the group, you can simply add 4 and 2 to get 6. The resulting set of permissions is as follows:

 chmod 6750 ftl_travel 

Changing the setuid bit (or setgid) is not strictly a case of providing administrative access to nonroot users. This can be anything. You might have a database package that operates under only one user ID, or you may want all users to access a program as though they were part of a specific group. You will have to decide.