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.
background
excerpt
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).
SUID/GUID
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.
excerpt
SETUID AND SETGID BITS
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.
excerpt
RESTRICTED DELETION FLAG OR STICKY BIT
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.
The text section of an executable is the actual executable code, this is what it refers to. On Linux this request is ignored, it is just an optimisation, made by the admin. The kernel can do this for it self, without the prompt.
It is saying that if the executable text gets swapped out, and the process ends, then keep it for next time. On linux (local)executables are not swapped out, as it is as quick to reload from file. Maybe it is a bit different for NFS.
The sticky bit has other meanings for other file types:
You described for executables.
For directories, it stops non owners from deleting files.
I assume that nfs is the same, when I used it 20 years ago it was.
from: http://netbsd.gw.com/cgi-bin/man-cgi?sticky+7+NetBSD-current
Later, on SunOS 4, the sticky bit got an additional meaning for files
that had the bit set and were not executable: read and write operations
from and to those files would go directly to the disk and bypass the
buffer cache. This was typically used on swap files for NFS clients on
an NFS server, so that swap I/O generated by the clients on the servers
would not evict useful data from the server's buffer cache.
Best Answer
No, the sticky bit was not like the set-UID or set-GID flags. It didn't effect any changes to process credentials.
What the sticky bit did was make the program text "sticky". It wasn't a misnomer, originally.
background: program image sections and shared text
In essence, without getting too deep into the details of executable file formats (which can, and have, filled books): The parts of program image files that are directly loaded into memory in order to run programs comprise machine code, constants, the startup values of (non-zero-initialized) variables, and (in one form or another) blank spaces for zero-initialized and uninitialized variables.
These are grouped into collections known as "sections" and they have conventional names. The machine code and (sometimes) the constants form what is often known as the "text" section of a program image. The non-zero-initialized variables are, similarly, the "data" section; and the zero-initialized and uninitialized variables are "bss" (a name which itself has a whole folkloric history behind it).
When a process has a program executable image file loaded into it, the various parts — text, data, and bss — are initialized from the contents of the image file.
What's special about the "text" section is that the machine code (and the constants) is almost always not written to. It has the potential to be shared across the virtual memory images of all executing process that had that executable image file loaded into them. The exact scenario in which program text can be shared is out of scope for this answer and involves things such as loader fixup idempotence and address space layout identity. People can and have written books about this subject, too. ☺
Shared text is an optimization employed by the kernel. It removes the need for every instance of a single running program image to have its own individual memory image, consuming precious physical memory with multiple copies of the exact same machine code (and constants).
sticky text
But one can do better still than shared text. Obviously, if there's always at least one process running that is using a particular shared text program image, the kernel gets to simply attach the new processes' virtual memory space to the existing shared text segment when a new instance of the program is run. There's almost always an instance of (say)
/bin/login
or/bin/sh
running somewhere on a mid-sized system, so new instances of the login program or the default shell can simply attach to the loaded copies of their text segments that the kernel has already loaded into memory.Sticky text extends this idea to program images that no process is currently running. If an executable image file is marked as sticky text, then the kernel keeps its text segment around after the last process to use it exits; in the hope that another instance of the program will execute soon, and can just attach back to the segment.
In early Unices, loaded sticky text segments would be swapped out to swap storage when no process was attached to them. (Later Unices stopped using swap for this.) You might also have heard of this by the name saved text.
Of course, setting the sticky text bit on a program image is something that has to be done with care. What programs benefit from it depend from what the machine is generally used for. And currently unattached text segments take up kernel resources, meaning that there is a practical limit to how many one can have in any system. So it is generally an operation that requires superuser privileges.
desuetude
There is a whole load of assumptions that underlies the operation of sticky text, that just aren't true any more. Reading a pre-made segment from swap storage isn't necessarily faster than simple demand paging in from the actual executable image file. Filesystem formats became better for random (as opposed to sequential) reading patterns. The advent of demand paging itself changes things, as do things like unified caches, non-idempotent external fixups resulting from differences in shared library search, and address space layout randomization.
The days of sticky text bits for executable program images are long gone. An explicit sticky text marker flag for executable program images was considered obsolete by the writers of 4.3BSD in the mid-1980s, for example.
Further reading