The sticky bit applied to executable programs flagging the system to keep an image of the program in memory after the program finished running.

But I don't know that what it's stored in memory. And how I can see them, in this case.?


4 Answers 4


This is probably one of my most irksome things that people mess up all the time. The SUID/GUID bit and the sticky-bit are 2 completely different things.

If you do a man chmod you can read about the SUID and sticky-bits. The man page is available here as well.



The letters rwxXst select file mode bits for the affected users: read (r), write (w), execute (or search for directories) (x), execute/search only if the file is a directory or already has execute permission for some user (X), set user or group ID on execution (s), restricted deletion flag or sticky bit (t).


What the above man page is trying to say is that the position that the x bit takes in the rwxrwxrwx for the user octal (1st group of rwx) and the group octal (2nd group of rwx) can take an additional state where the x becomes an s. When this occurs this file when executed (if it's a program and not just a shell script) will run with the permissions of the owner or the group of the file.

So if the file is owned by root and the SUID bit is turned on, the program will run as root. Even if you execute it as a regular user. The same thing applies to the GUID bit.



chmod clears the set-group-ID bit of a regular file if the file's group ID does not match the user's effective group ID or one of the user's supplementary group IDs, unless the user has appropriate privileges. Additional restrictions may cause the set-user-ID and set-group-ID bits of MODE or RFILE to be ignored. This behavior depends on the policy and functionality of the underlying chmod system call. When in doubt, check the underlying system behavior.

chmod preserves a directory's set-user-ID and set-group-ID bits unless you explicitly specify otherwise. You can set or clear the bits with symbolic modes like u+s and g-s, and you can set (but not clear) the bits with a numeric mode.

SUID/GUID examples

no suid/guid - just the bits rwxr-xr-x are set.

$ ls -lt b.pl
-rwxr-xr-x 1 root root 179 Jan  9 01:01 b.pl

suid & user's executable bit enabled (lowercase s) - the bits rwsr-x-r-x are set.

$ chmod u+s b.pl 
$ ls -lt b.pl 
-rwsr-xr-x 1 root root 179 Jan  9 01:01 b.pl

suid enabled & executable bit disabled (uppercase S) - the bits rwSr-xr-x are set.

$ chmod u-x b.pl
$ ls -lt b.pl 
-rwSr-xr-x 1 root root 179 Jan  9 01:01 b.pl

guid & group's executable bit enabled (lowercase s) - the bits rwxr-sr-x are set.

$ chmod g+s b.pl
$  ls -lt b.pl 
-rwxr-sr-x 1 root root 179 Jan  9 01:01 b.pl

guid enabled & executable bit disabled (uppercase S) - the bits rwxr-Sr-x are set.

$ chmod g-x b.pl
$  ls -lt b.pl 
-rwxr-Sr-x 1 root root 179 Jan  9 01:01 b.pl

sticky bit

The sticky bit on the other hand is denoted as t, such as with the /tmp directory:

$ ls -l /|grep tmp
drwxrwxrwt. 168 root root 28672 Jun 14 08:36 tmp

This bit should have always been called the "restricted deletion bit" given that's what it really connotes. When this mode bit is enabled, it makes a directory such that users can only delete files & directories within it that they are the owners of.



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.

  • 53
    Actually the sticky-bit could previously be applied to executables, which caused these to remain in swap after they first were loaded. This could save lots of unnecessary disk/network (NFS) and CPU usage for programs that were much used. However, neither Linux nor most (all?) Unix systems support this any longer (it was removed from the kernel). It's "sticky", because the executable stuck in swap. In addition, it was used for directories as you describe. Jun 14, 2013 at 13:38
  • 4
    Actually "much used or very big" would be a better description. Remember my college had the Netscape web-browser as "sticky" on their HP-UX computer back in 1995. So small programs that were very often used (eg. system-commands ran frequently by cron) and large programs (eg. Netscape) were prime candidates to be made "sticky". In both cases, constantly reloading them from disk/NFS would be wasteful. Jun 14, 2013 at 14:48
  • 12
    Sticky-bit programs were meant to stay resident in RAM, not in swap (loading an image from a swap file isn't that much faster than loading it from a filesystem disk). It was intended for essential OS-level commands like ls. Obviously, only the superuser could set the sticky bit on a file. It became less important after virtual memory and shared libraries were introduced, and especially as pagers became smarter and can dynamically decide which pages to keep resident.
    – alexis
    Jun 14, 2013 at 18:04
  • 5
    And since the sticky property made no sense for a directory, the same bit of the permissions mask was later interpreted to modify the traditional file-creation semantics for directories.
    – alexis
    Jun 14, 2013 at 18:07
  • 5
    @alexis: Originally, sticky bit programs were kept in swap space. This was much faster than reading from the filesystem because reading swap file images were contiguous sectors and so could be read mostly asynchronously. With the early filesystems, there were no sector "run lengths" and most early filesystem drivers read one sector at a time even if the sectors happened to be consecutive. The result on a PDP-40 was sticky programs seemed to load instantly while non-sticky programs took the usual second or two. I think we had only ed sticky.
    – wallyk
    Sep 22, 2015 at 18:05

"The sticky bit applied to executable programs flagging the system to keep an image of the program in memory after the program finished running."

I think that's quite obsolete info, today most modern Unixes ignore that. In Linux, the sticky bit is only relevant for directories. See here and the quite informative Wikipedia article.

Anyway, in that old behaviour the image (only the "code", not the data) was only kept in virtual memory -normally swapped, not in real memory, so as to run it faster next time.


What are sticky bits ?

A sticky bit is a permission bit that is set on a directory that allows only the owner of the file within that directory or the root user to delete or rename the file. No other user has the needed privileges to delete the file created by some other user.

This is a security measure to avoid deletion of critical folders and their content (sub-directories and files), though other users have full permissions.

  • 1
    That's not right: en.wikipedia.org/wiki/Sticky_bit
    – A.B.
    Apr 19, 2015 at 15:01
  • 8
    @A.B. It seems pretty accurate to me, almost to the point of paraphrasing the beginning of the Wikpedia article you cite. What's wrong with it?
    – roaima
    Apr 19, 2015 at 15:42
  • I would say that the answer is incomplete. "Sticky" also denotes that the executable would be kept in the swap space to get it running quicker. Now, this is ancient history but in older file systems drivers used to read one sector at a time even if the sectors happened to be consecutive. This made non-sticky executables to be slow, stickiness made a whole lot of sense at that time.
    – GhostCode
    Aug 22, 2019 at 10:38

What I miss in this answer is, that sticky bit for a directory is used also in a way, that when set, the group for new file in that directory is the same as for the directory.

  • 3
    I'm not sure if you meant this as a comment on another answer, but if so, you should post it there with the "Add a comment" link, not as a separate answer. But as far as the functionality of setting the group is concerned, do you have any source for that claim? Because at least on Linux, that's controlled by the set-group-ID / setgid bit, not the sticky bit, see e.g. the open(2) man page, under the description of O_CREAT: "The group ownership of the new file [...] depends on whether the set-group-ID mode bit is set"
    – ilkkachu
    Dec 12, 2021 at 22:07
  • Which answer are you referring to? {Edit] your answer and add the link to the answer being referenced in your post. Dec 13, 2021 at 3:34
  • 1
    setuid & setgid ≠ stickbit Jul 24, 2022 at 14:39

You must log in to answer this question.

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