In an earlier article, we discussed the purpose of SUID, an advanced file permision. In the same lines, Sticky bit is also an advanced file permission used in Unix/Linux or its flavors. This feature was originally meant for regular files and directories, though is now used only in directories in many Unix flavors. This permission, when applied on a directory, allows users to maintain 'their' files in directories which are shared with everybody.
In any Unix flavor, directories are created at times with full permissions which are shared or accessed by everybody. Say, for example the '/tmp' directory. /tmp directory is accessible for each and every user, where the user can read, create/write and remove files. A careful look at the file permissions of the /tmp directory shows 777 which according to file permission definitions of directory, should allow every user even to edit or delete other user files. However, any user will be able to edit or delete only the files created by himself, not the files created by other users. How is it possible? This is where the 'sticky bit' comes in. Note the sticky bit present in the /tmp directory:
$ ls -ld /tmp drwxrwxrwt 27 root root 4096 Aug 17 18:48 /tmpThis sticky bit allows users to edit and remove files only belonging to them alone, not by others users, at the same time allowing the other users to create their own files and maintain them. To simplify it, sticky bit on this /tmp directory means "all permissions to the world but do not touch my files".
Let us create a scenario and try to understand this sticky bit in detail. For our simplicity, we consider 2 users: user1 and user2:
1. User1 creates a directory, say "test" under the /tmp and creates a file, say 'file1':
$ echo $USER user1 $ pwd /tmp $ mkdir test $ chmod 777 test $ ls -ld test drwxrwxrwx 2 user1 dba 4096 Aug 17 18:48 test $ cd test $ touch file1 $ ls -l file1 -rw-r--r-- 1 user1 dba 0 Aug 17 18:48 file12. User2 now tries to remove the file "file1":
$ echo $USER user2 $ pwd /tmp/test $ ls file1 $ rm file1 $user2 was able to remove the file since the 'test' directory has 777 permissions which means world editable. And hence anybody can create, edit or delete anybody's files in this 'test' directory.
3. user1 now applies the 'sticky bit' to control this mess and creates a file:
$ pwd /tmp $ chmod +t test $ ls -ld test drwxrwxrwt 2 user1 dba 4096 Aug 17 18:48 test $ cd test $ touch file1 $ ls file1
Did you think why can't user1 simply remove 'write' permission to others from the test directory? By removing the write permission, user1 will be successful in preventing the user2 from removing his files. However, this move will also prevent user2 from creating his own files in the test directory. Hence, the sticky bit which is equal to "all permissions", at the same time "do not touch my files".
4. user2 now tries to delete the file 'file1':
$ pwd /tmp/test $ ls file1 $ rm file1 rm: cannot remove `file1': Operation not permitted $ mv file1 f1 mv: cannot move `file1' to `f1': Operation not permittedAs seen, the file is no longer removable or renamable. The file 'file1' can now be edited only by the owner of the file 'user1' or by the root user.
5. The user 'user2' can still create files, however, and edit or remove files which he has created.
$ touch file2 $ ls -l total 12 -rw-r--r-- 1 user1 dba 0 Aug 17 18:52 file1 -rw-r--r-- 1 user2 vmw 8 Aug 17 18:53 file2 $ cat > file2 welcome ^C $ rm file2 $user2 was able to create a file 'file2' and he was able to delete the file created by himself.
P.S: Sticky bit on regular files, though unused today in Linux, was originally meant to speed up execution. This bit on regular files was meant to be set on executables. Executables with sticky bit set are maintained in the swap space itself, so that the next time the executable is required, it can directory be run from swap memory, instead of getting it from the hard disk.