Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Sticky bit are mentioned in every UNIX security book, but I couldn't find anyone that describes the exploitation of Sticky Bit set on a file.

Can you?

share|improve this question
What do you mean? Are you looking for the uses of sticky bits on files? Are you looking for the security risks in enabling sticky bits (most modern unices ignore them anyway)? If you're curious about what you read in a particular book, it would help to summarize here what you read. P.S. Are you sure you mean sticky bits (which aren't particularly security-related) and not setuid/setgid bits (which definitely are)? – Gilles Nov 21 '11 at 18:45
cp /usr/bin/lua /usr/bin/crontab - if permissions allow the user to write the file would create an instance of lua running as root – symcbean Nov 22 '11 at 17:14
Is it possible you mean the setuid bit, not the sticky bit? They are very different. Please read the manual, and Google on them to do some background research before asking here: there has been a lot written on this subject. – D.W. Nov 23 '11 at 3:46
@D.W.: No. Since I never take anything for granted I just tried this out on a RH5.1 box - it worked exactly as I expected. (yes I was refering the setuid bit rather than the sticky bit) – symcbean Nov 23 '11 at 10:31
@symcbean, well, time for me to eat crow. I was the one who was confused. My sincere apologies. It turns out this is OS-dependent (C2 OS's are required to clear the setuid/setgid bits any time a file is written), but Linux does not clear setuid bits when the file is written, if the file is written by root. (That said, if the attacker can get access to the root account, then there are a million ways for the attacker to do really bad things, setuid bit or no.) What is true on Linux is that the setuid bit is cleared if a non-root user writes the file or if root makes the file writeable by others. – D.W. Nov 23 '11 at 17:03
up vote 11 down vote accepted

man chmod #Debian Linux


The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type. For directories, it prevents unprivileged users from removing or renaming a file in the directory unless they own the file or the directory; this is called the restricted deletion flag for the directory, and is commonly found on world-writable directories like /tmp. For regular files on some older systems, the bit saves the program's text image on the swap device so it will load more quickly when run; this is called the sticky bit.

Note that the "on some older systems" part applies to various BSD systems. Linux has never had any special handling for the sticky bit on files. See for more detail about that.

From a security standpoint, it's really just about understanding why that permission exists on the /tmp directory, and possibly others. It prevents users from deleting the files of others in a directory that can be written to by multiple users. It's really only an issue if you don't set it and somebody gets delete happy on others' files.

share|improve this answer
It is true, if the sticky bit is missing on /tmp, an attacker can deleting the files of other user's. However he can also create another file by the same name. This means, he/she can replace a file (usually without the former user noticing). – hagello Dec 21 '15 at 8:00

Even though the OP realized that he confused the sticky bit (t) with the setuid/setgid bits (s), I want to give a "real-life scenario" for a missing sticky bit on a directory:

If you use an old-style text mail program like mutt and start compose mail, the following happens (roughly):

  1. mutt creates a temporary file in /var/tmp
  2. mutt starts your text editor with the name of the temporary file
  3. mutt pauses
  4. you compose your text and save it
  5. you quit the text editor
  6. mutt reads the contents of the temporary file and sends it.
  7. mutt deletes the temporary file

An attacker may replace the file containing the text of your mail between step 4 and step 6. The reason is that the directory for temporary files has to be world writeable to be usable for all users. This attack works even if the file itself has access mode 0600, because having the right to create, replace or delete a file depends on the write permission bits on the directory.

The sticky bit prevents an attacker from deleting (system call unlink) or replacing (rename) a file of another user even if the the attacker has write permission on the directory.

Modifying a file depends on the write access bits (and the ownership) of the file itself.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.