Sticky attribute (sticky bit) in Unix

• Introduction
• Setting and unsetting sticky bit
• Note about mounting a new partition on /tmp
• History and origin of the concept of sticky bit

Introduction

The sticky bit is a special permission that protects the files within a publicly writable directory. If the directory permissions have the sticky bit set, a file can be deleted only by the owner of the file, the owner of the directory, or by the root user. This prevents a user from deleting other users’ files from publicly writable directories.

Note: If a letter "t" appears in the execute field for other, it indicates that the sticky bit is on

while in the past it was used on files, currently the most common use of the sticky bit today is on directories.

When the sticky bit is set, only the item's owner, the directory's owner, or the superuser can rename or delete files. Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of owner.

Typically this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files.

This feature was introduced in 4.3BSD in 1986 and today it is found in most modern Unix systems.

In addition, Solaris (as of Solaris 2.5) defines special behavior when the sticky bit is set on non-executable files: those files, when accessed, will not be cached by the kernel. This is usually set on swap files to prevent access on the file from flushing more important data from the system cache. It is also used occasionally for benchmarking tests. The sticky bit is also set by the automounter to indicate that a file has not been mounted yet. This allows programs like ls to ignore unmounted remote files.

Setting and unsetting sticky bit

Use the ls command to determine if a directory has the sticky bit permission set.

# ls -ld /tmp
drwxrwxrwt 9 root root 4096 Dec 4 15:59 /tmp

As you can see the sticky bit displayed as the letter "t" in the execute field for other.

The root user and the owner can set the Sticky Bit permission on directories by using the chmod command and the octal value 1###. Here is the command-line format:

chmod 1777 /tmp

You can also use the command chmod +t /tmp

To search for directories that have sticky bit permissions and display their full path names, execute the following command:

find / -type d -perm -1000

Note:  On Solaris for a more detailed information on the sticky bit, execute the man sticky command.

Note about mounting a new partition on /tmp

In Linux if you created a new partition (say on a new disk) and try to mount it, say, on /tmp (for example to enlarge partition) you can lose sticky bit on /tmp partition.

That is connected with the implemented concept of mounting. When a partition is mounted then the root directory of the partition substituted (overlay) the directly on which it is mounted). And by default permission for this newly-created "hidden" root directory are defined by umsk. It is something like 755, never 1777.  

Similarly if you unmount old /tmp and mount it of, say, /srv, this directory magically will get permission 1777 despite the fact that before that the permission were 755.

History and origin of the concept of sticky bit

A very long time ago, UNIX ran on machines with much less memory than today: 64 kilobytes, for instance. This amount of memory was expected to contain a copy of the operating system, I/O buffers, and running programs. This memory often wasn't sufficient when there were several large programs running at the same time. The sticky bit was introduced in the Fifth Edition of Unix in 1974 for use with so called pure executable files. When set, it instructed the operating system to retain the text segment of the program in swap space after the process exited. This sped up subsequent executions by allowing the kernel to make a single operation of moving the program from swap to real memory. Thus, frequently-used programs like editors would load noticeably faster.

One notable problem with "stickied" programs was replacing the executable (for instance, during patching); to do so required removing the sticky bit from the executable, executing the program and exiting to flush the cache, replacing the binary executable, and then restoring the sticky bit.

Currently, this behavior is only operative in HP-UX, NetBSD, and UnixWare. Solaris abandoned this in 2005. The 4.4-Lite release of BSD retained the old sticky bit behavior but it has been subsequently dropped from OpenBSD (as of release 3.7) and FreeBSD (as of release 2.2.1); it remains in NetBSD.

To make the most of the limited memory, UNIX swapped processes to and from secondary storage as their turns at the CPU ended. When a program was started, UNIX would determine the amount of storage that might ultimately be needed for the program, its stack, and all its data. It then allocated a set of blocks on the swap partition of the disk or drum attached to the system. (Many systems still have a /dev/swap, or a swapper process that is a holdover from these times.)

Each time the process got a turn from the scheduler, UNIX would swap in the program and data, if needed, execute for a while, and then swap out the memory copy if the space was needed for the next process. When the process exited or exec'd another program, the swap space was reclaimed for use elsewhere. If there was not enough swap space to hold the process's memory image, the user got a "No memory error " (still possible on many versions of UNIX if a large stack or heap is involved.)

Obviously, this is a great deal of I/O traffic that could slow computation. So, one of the eventual steps was development of compiler technology that constructed executable files with two parts: pure code that would not change, and everything else. These were indicated with a special magic number in the header inside the file. When the program was first executed, the program and data were copied to their swap space on disk first, then brought into memory to execute. However, when the time comes to swap out, the code portions were not written to disk - they would not have changed from what was already on disk! This change was a big savings.

The next obvious step was to stop some of that extra disk-to-disk copying at start-up time. Programs that were run frequently - such as cc, ed, and rogue - could share the same program pages. Furthermore, even if no copy was currently running, we could expect another one to be run soon. Therefore, keeping the pages in memory and on the swap partition, even while we weren't using them, made sense. The "sticky bit" was added to mark those programs as worth saving.

Since those times, larger memories and better memory management methods have largely removed the original need for the sticky bit.

NEWS CONTENTS

• 190813 : The sticky bit and directories ( The sticky bit and directories, )
• 190813 : UNIX - Linux How to Use Sticky Bit on Directory and File ( UNIX - Linux How to Use Sticky Bit on Directory and File, )
• 190813 : The sticky bit and directories ( )

Old News ;-)

The sticky bit and directories

Another important enhancement involves the use of the sticky bit on directories. A directory with the sticky bit set means that only the file owner and the superuser may remove files from that directory. Other users are denied the right to remove files regardless of the directory permissions. Unlike with file sticky bits, the sticky bit on directories remains there until the directory owner or superuser explicitly removes the directory or changes the permissions.

You can gain the most security from this feature by placing the sticky bit on all public directories. These directories are writable by any non-administrator. You should train users that the sticky bit, together with the default umask of 077, solves a big problem for less secure systems. Together, both features prevent other users from altering or replacing any file you have in a public directory. The only information they can gain from the file is its name and attributes.

``Sticky bit example'' illustrates the power of such a scheme. The sticky bit is the ``t'' in the permissions for the directory.

UNIX - Linux How to Use Sticky Bit on Directory and File

Use chmod command to set the sticky bit. If you are using the octal numbers in chmod, give 1 before you specify other numbered privileges, as shown below. The example below, gives rwx permission to user, group and others (and also adds the sticky bit to the directory).

$ chmod 1777 dir

Or, you can assign only sticky bit to an existing directory (without touching any other user, group and other privileges) using chmod command as shown below.

$ chmod +t dir

Once the sticky bit is assigned to a directory, you'll see (t) as the last character in the permission. In this example, it is drwxrwxrwt.

$ ls -ld /home/bala/dir
drwxrwxrwt 2 bala bala 4096 2011-01-28 14:09 /home/bala/dir
$ ls -l dir
total 8
-rwxrwxrwx 1 bala   bala   20 2011-01-28 14:12 bala.txt
-rwxrwxrwx 1 guest guest 41 2011-01-28 14:13 guest.txt

In the above example, as dir has rwx permission to everybody, all other users are allowed to do create their files or directories under this directory. However, even when the sub-directories or files under dir is having rwx permission to everybody, only the owner of those can delete or rename those files and directory. Other users cannot delete or rename it because of sticky bit.

The sticky bit and directories

Another important enhancement involves the use of the sticky bit on directories. A directory with the sticky bit set means that only the file owner and the superuser may remove files from that directory. Other users are denied the right to remove files regardless of the directory permissions. Unlike with file sticky bits, the sticky bit on directories remains there until the directory owner or superuser explicitly removes the directory or changes the permissions.

You can gain the most security from this feature by placing the sticky bit on all public directories. These directories are writable by any non-administrator. You should train users that the sticky bit, together with the default umask of 077, solves a big problem for less secure systems. Together, both features prevent other users from altering or replacing any file you have in a public directory. The only information they can gain from the file is its name and attributes.

``sticky bit example'' illustrates the power of such a scheme. The sticky bit is the ``t'' in the permissions for the directory.

sticky bit example

   $ id
   uid=76(slm) gid=11(guru)
   $ ls -al /tmp
   total 64
   drwxrwxrwt   2 bin      bin      1088 Mar 18 21:10 .
   dr-xr-xr-x  19 bin      bin       608 Mar 18 11:50 ..
   -rw-------   1 blf      guru    19456 Mar 18 21:18 Ex16566
   -rw-------   1 blf      guru    10240 Mar 18 21:18 Rx16566
   -rwxr-xr-x   1 slm      guru    19587 Mar 17 19:41 mine
   -rw-------   1 slm      guru      279 Mar 17 19:41 mytemp
   -rw-rw-rw-   1 root     sys        35 Mar 16 12:27 openfile
   -rw-------   1 root     root       32 Mar 10 10:26 protfile
   $ rm /tmp/Ex16566
   rm: /tmp/Ex16566 not removed. Permission denied
   $ rm /tmp/protfile
   rm: /tmp/protfile not removed. Permission denied
   $ cat /tmp/openfile
         Ha! Ha!
   You can't remove me.
   $ rm /tmp/openfile
   rm: /tmp/openfile not removed. Permission denied
   $ rm -f /tmp/openfile
   $ rm /tmp/mine /tmp/mytemp
   $ ls -l /tmp
   drwxrwxrwt   2 bin      bin      1088 Mar 18 21:19 .
   dr-xr-xr-x  19 bin      bin       608 Mar 18 11:50 ..
   -rw-------   1 blf      guru    19456 Mar 18 21:18 Ex16566
   -rw-------   1 blf      guru    10240 Mar 18 21:18 Rx16566
   -rw-rw-rw-   1 root     sys        35 Mar 16 12:27 openfile
   -rw-------   1 root     root       32 Mar 10 10:26 protfile
   $ cp /dev/null /tmp/openfile
   $ cat /tmp/openfile
   $ cp /dev/null /tmp/protfile
   cp: cannot create /tmp/protfile
   $ ls -l /tmp
   drwxrwxrwt   2 bin      bin      1088 Mar 18 21:19 .
   dr-xr-xr-x  19 bin      bin       608 Mar 18 11:50 ..
   -rw-------   1 blf      guru    19456 Mar 18 21:18 Ex16566
   -rw-------   1 blf      guru    10240 Mar 18 21:18 Rx16566
   -rw-rw-rw-   1 root     sys         0 Mar 18 21:19 openfile
   -rw-------   1 root     root       32 Mar 10 10:26 protfile

The only files removed are those owned by user slm (the user in the example). The user slm could not remove any other file, even the accessible file /tmp/openfile. However, the mode setting of the file itself allowed slm to destroy the file contents; this is why the umask setting is important in protecting data. Conversely, the mode on /tmp/protfile, together with the sticky bit on /tmp, makes /tmp/protfile impenetrable.

All public (world writable) directories should have the sticky bit set. These include, but are not limited to:

• /tmp
• /usr/tmp
• /usr/spool/uucppublic

If you are unsure, it is far better to set the sticky bit on a directory than to leave it off. You can set the sticky bit on a directory with the following command, where directory is the name of the directory:

chmod u+t directory

To remove the bit, replace the ``+'' with a ``-'' in the chmod command.

Recommended Links

sticky bit - Wikipedia, the free encyclopedia

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019