PRE-REQ: familiar with chmod and chown & user/group/other & read/write/execute
This article will not have many commands, it will just be on concepts. There are plenty of technical command articles all over:
*http://linux.die.net/man/7/credentials
*http://www.thegeekstuff.com/2011/02/sticky-bit-on-directory-*file/
*http://en.wikipedia.org/wiki/Setuid
*http://en.wikipedia.org/wiki/Chmod#Special_modes
We are all familiar with the chmod 000 thru chmod 777
However Have you ever seen this notation, where they add another digit? chmod 0000 thru 7777
So whats the business with that extra digit to the left of our regular ###s?
So the first (from the right) are obvious, its read/write/execute for user/group/other
chmod ### = chmod user/group/other
The new digit adds an extra attribute and whole new set of options. By default this value is 0 or its not set to anything (so its not set to setgid, not set to setuid, and not set to stickybit).
So in reality chmod 777 is the same as chmod 0777. or chmod 0421 is the same as chmod 421
chmod #### = chmod extra-options/user/group/other
So what are these extra options? Why do we need them?
Well they are the sticky bit (which is set/unset with +t/-t using chmod) and there is also the setgid and setuid bit (which is set with +s/-s using chmod). And they give more options that were needed and they solved some problems in an easy way.
* Sticky bits set on files dont dont do anything. But they do things when set on directories. I read that on older *nix systems, the sticky bit enabled executable files to bel oaded to the swap memory after 1st execution, which sped up the subsequent executions (this is no longer true with newer systems).
* Sticky bit (on directories): Think of the meaning behind a “sticky” file (or directory), sticky implies it sticks – so it cant go away. It cant get deleted (or renamed). The sticky bit does just that. It makes it so a file can only be renamed or deleted by the files owner or root user. The sticky bit is applied to folders. Sticky bits were invented obviously for security, so that users cant delete other users files.
* SetUid/SetGid bit: Applies differently to files and to folders. Both explanation are below. SetUid/SetGid set on a file that doesnt have execute bit does nothing. Just like stickybit set on a file does nothing. It can be set but it has no effect.
* SetUid/SetGid bit (to executable files): When using windows, you know how you can right click on something an “run it as administrator” or likewise in linux you can “sudo COMMAND” some random command (such as COMMAND, if such a command existed). Anyhow “sudo” gives you temporary privileges to be root, even though you can be some other user such as “bob”. However someone must of allowed “bob” to use “sudo” in that /etc/sudoers file. Well the SetUid and SetGid allow any user that can execute a program, to run that program with the UiD or GiD of the owner or group owner of the – without it the UiD and GiD will just be that of the current user and the users primary group (primary group can be seen with “id” or “group” command). Whether a user is allowed to execute that program relies on the first 3 permission bits we are all familiar with (see PRE-REQs at the top). This is useful to give temporary elevated privileges to a program. Care must be provided into the coding of the program so that the program cannot do anything dangerous to the system. An example is the passwd command, any user can use that program to change their own password (and the root user can run it to change anyones password). However not every user can edit or read /etc/passwd file. The passwd command has to edit /etc/passwd file, but how does it do so with a non-root user (such as “bob”, because “bob” decided to change his password)? Well the setuid and setgid give the user “bob” temporary permission to run as the user & group of the program passwd (which if you look is root/root). usually bobs uid and gid will “bob” and “bob” (or whatever group bob is in). However when running passwd (and only during the execution of tha passwd command) bobs uid becomes “root” and gid “root”. Another common program that needs this is the ping programm it must send and listen to control packets on a network interface, and that requires elevated privileges.
* SetUid/SetGid bit (to folders): This is useful for a folder that you want a whole group to access indefinitely. Wikipedia says it best: Setting the setgid permission on a directory causes new files and subdirectories created within it to inherit its group ID,rather than the primmary group ID of the user who created the file (the owner ID is never affected, only the group ID). Newly created subdirectories inherit the setgid bit. So anyone that belongs to the group “students” can go into a folder called “discussions” (which has the setgid set) and when they make a file there, those files will have the group owner set as “students” instead of whatever the students group is (typically a users group is themselves, each user has a corresponding group with the same name).
Side track to Effective/Real/Saved UIDs
With setuid / setgid operating on files. Its interesting to take a look at how this happens using the system 3 variables for keeping track of the user ids. Lets take a look at the passwd program which when run with any user other than root allows the user to change only their own password. Where as root can change anyones password using passwd (because it has full access to the /etc/passwd file thus it can change anyones password)
For the sake of your own knowing. Root user has a uid of 0.
–The Real Uid (Uid of the user that created the process): So lets say “bob” is using the system. An he invokes the passwd program. The REAL UiD in this case is “bob”
–The Effective Uid (action uid): Now since setuid bit is set on passwd and the user owner of passwd is root. Bobs effective UiD becomes “root”, but only for the executation of the “passwd” program (we dont want him getting extra privileges anywhere else).
When programs run, they run thier commmands with the priviledge of the Effective Uid not the Real UiD. Thus, The effective Uid is what is effective, the Real Uid is what is really going on. So What really is going on, is that “bob” is using passwd, but he gets to use it effectively as “root”. Now without the use of setuid/setgid Effective Uid and Real Uid are always the same. So passwd is run and it knows it has privildges as root, it thinks its root. So the question now is this, how does passwd know to change “bobs” password and not someone elses, afterall its effectively running as root? Well the answer is the Real UID. passwd can peek at the Real UID and know that bob is running passwd after all.
–Saved Uid: This is set to the effective ID when the program starts. This is used a place-holder, memory, to help remember what the original effective uid was. Without it if you changed the effective uid, you would have to manually keep track of the original. The linux kernel is nice enough to remember that for you.
*If you start a program as yourself, and it does not have its set ID upon execute bit set, then the program will start running with its real, effective, and saved IDs set to your user ID.
*If you run a setuid program, your real ID remains unchanged, but your effective and saved IDs are set to the owner of the file. The effective id can the be changes through out the duration of the programs run (using simple c programming language commands, or using any other programming language). You can always go back to the original effective id by looking at the Saved Uid.
Who can change Real/Effective and Save UiDs?
– Real Uid: since this keeps track of who created the process, this can only be changed by the root user effectivly. So if the process has an Effective UID of root user (0) then the Real Uid can be changed to anything.
– Effective UID: If the Effective UID is 0/root, then the Effective UID can be changed to anything. If the Effective UID is not root (not 0) then the Effective UID can only be change to the value or the Real UID or the Saved UID.
– Saved UID: unclear in research. Im assuming this is unchanged. However if your effective UID is 0/root then this can be changed.
So normally a program executes like this (pretend 1000 is bob):
– real: 1000
– effective: 1000
– saved: 1000
Now if run on program called “passwd” (And the passwd program has the user owner as root) then the following UIDs are set
– real: 1000
– effective: 0 <– notice since this is 0, passwd can easily change the “real” uid.
– saved: 0
Now if there is another program called “other123” (and it has setuid bit set and it has user owner as “jesse”/uid 1002) then the following UIDs are set when bob launches it:
– real: 1000
– effective: 1002
– saved: 1002
“su” works by changing all 3 uids to whatever user you want to become. Plus it does other things.
good reads on this UID stuff:
*http://www.lst.de/~okir/blackhats/node23.html
*http://timetobleed.com/5-things-you-dont-know-about-user-ids-that-will-destroy-you/
*http://stackoverflow.com/questions/205070/whats-the-deal-with-all-the-different-uids-a-process-can-have