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?

  • 4
    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)? Commented Nov 21, 2011 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
    Commented Nov 22, 2011 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.
    Commented Nov 23, 2011 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
    Commented Nov 23, 2011 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.
    Commented Nov 23, 2011 at 17:03

2 Answers 2


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 http://en.wikipedia.org/wiki/Sticky_bit 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.

  • 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
    Commented Dec 21, 2015 at 8:00
  • If you can create another file with the same name in a directory you're having much more bitter issues other than security's.
    – poige
    Commented Sep 7, 2017 at 13:38

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .