windsor - 12:36 am on Feb 9, 2002 (gmt 0)

/tmp isn't world writable because of the sticky bit, it's world-writable because of the permissions (777 or 0777 or ugo+rwx or a+rwx, depending on how you want to look at it).

By default, if you own the directory or have the proper permissions, you have the authority to remove files from it. This is done at the directory level instead of the file level because when you create or remove a file, you are adding or removing an entry in the directory (think of it as altering the contents of the directory).

This creates a problem with scratch areas that all users can toss files in, such as /tmp. User "joe" could put a file in /tmp and user "jane" could delete it (because jane has rwx access to the directory).

The sticky-bit on directories forces the behavior that (within that directory with the sticky-bit set) only the owner of the file can remove the file. The same applies to directories within that directory that has the sticky-bit set. To continue the above example, joe could also create a directory in /tmp that jane couldn't remove.

The "Set User", "Set Group", sticky-bit bits are tied to the execute bit. When you're looking for them, look at the three places where you expect to see a `x'. SUID/SGID bits change the `x' to a `s'. Sticky-bits change the last `x' to a `t'. All of these bits do different things, depending on whether you set them on files or dirs. To add complication to the issue, some flavors of UNIX behave differently than others in this area, particularly with directories and SUID/SGID bits set. To stir up the pot even more, SUID/SGID/sticky-bit settings behave differently depending on if the relevant "Execute" ("x") bit is set or not.

We'll only talk about SUID/GID/sticky-bit settings as they are with the execute bit set, and only in their most common usage (SUID/SGID with files, sticky-bit on dirs).

"man ls" will generally tell you how your UNIX-like OS handles this mess (or refer you to another manpage that will).

Yes, yet another reference to those silly manpages :)

On the note of number counting, Air made the excellent connection that you merely count bits. These happen to be "Octal" numbers, meaning "0-7" (Get it? "octal", as-in "only eight"?) It isn't a coincidence that there are three bits to make one octal "digit", either, (2)³ (or 2*2*2) is 8.

SUID/SGID/sticky-bits are counted in similiar manner as the rwx bits, but as an add-on. You count 4-2-1 just like above, but this time we're talking only about the "new" bit and you're defining "where to place it". 4 means "user", 2 means "group", and 1 means "other" (left-to-right, just like the rwx sequence).

So, to use one of these "new" bits with the chmod(1) command, you could do "u+s" to set the SUID bit on "user". You could also add it to the numeric by making it the fourth number, adding it to the left side. For example, "chmod 4755 foo" is fairly common practace (meaning, SUID, rwx for owner, r-x for group and other). Sometimes you'll see a "chmod 0644" or similiar with a leading `0'. That is a way to tell chmod(1) to clear any SUID/SGID/sticky-bits. It is generally good practice to toss in a leading `0' when using chmod(1) with numbers when you aren't explicitly setting the SUID/SGID/sticky-bit.

Oh, and lastly, the infamous /tmp. You set the sticky-bit on it a-la "chmod 1777 /tmp" or "chmod a+rwx,u+t /tmp". Solaris requires that you "u+t", BSD allows you to use "g+t" but not "o+t", dunno what linux does. man chmod for specifics. You'll find that most folks don't deal with "chmod ...+t" when setting the sticky-bit, they'll just "1777" it instead (since the only time you set it is with a+rwx dirs).

When I think about SUID/SGID/sticky-bits, I think of *all* of them as "sticky bits" and we're merely determining where to place it. Placement, of course, defines its behavior. Technically, this is not the correct terminology, but it sure makes things easier to remember.

Rob++