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.