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.

$ touch fish 

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

$ ls -l -rw-r--r-- 1 mgagne mgagne 0 2006-03-10 14:31 fish 

Without doing anything whatsoever, your file has read and write permissions for both the user and 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.

$ umask 0022 

The 2 is subtracted from the possible set of permissions, rwx (or 7). 7 0 remains 7, while 7 2 is 5. But wait5 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 get a symbolic mask displayed.

$ 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 creates text files that you want everyone to be able to read (444). Because the execute bit isn't a factor anyway, if you mask out the write bit using a 2 all around, 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.

 marcel@ubuntu:~$ umask 222 marcel@ubuntu:~$ touch duck marcel@ubuntu:~$ ls -l -r--r--r-- 1 mgagne mgagne 0 2006-03-10 15:26 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 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 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. 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, you can also 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 have to decide.

Important Note

You cannot use the setuid or setgid bit for shell scripts (although there are Perl hooks to do this). This doesn't work for security reasons. If you need to have a script execute with a set of permissions other than its own, you have to write a little C program that wraps around your script and then allows the program rather than the script to have setuid (or setgid) permissions.

The lesson here is that making something setuid immediately raises security issues. Know why you are taking this approach and consider the risks.

Moving to Ubuntu Linux
Moving to Ubuntu Linux
ISBN: 032142722X
EAN: 2147483647
Year: 2004
Pages: 201

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net