To set the sticky bit on a directory, why do the commands chmod 1777
and chmod 3777
both work?
Why does “chmod 1777” and “chmod 3777” both set the sticky bit
chmodpermissions
Related Solutions
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.
This is a configuration that allows members of a group, acltest, to create and modify group files while disallowing the deletion and renaming of files except by their owner and "others," nothing. Using the username, lev and assuming umask of 022:
groupadd acltest
usermod -a -G acltest lev
Log out of the root account and the lev account. Log in and become root or use sudo:
mkdir /tmp/acltest
chown root:acltest /tmp/acltest
chmod 0770 /tmp/acltest
chmod g+s /tmp/acltest
chmod +t /tmp/acltest
setfacl -d -m g:acltest:rwx /tmp/acltest
setfacl -m g:acltest:rwx /tmp/acltest
ACL cannot set the sticky bit, and the sticky bit is not copied to subdirectories. But, you might use inotify or similar software to detect changes in the file system, such as new directories, and then react accordingly.
For example, in Debian:
apt-get install inotify-tools
Then make a script for inotify, like /usr/local/sbin/set_sticky.sh
.
#!/usr/bin/env bash
inotifywait -m -r -e create /tmp/acltest |
while read path event file; do
case "$event" in
*ISDIR*)
chmod +t $path$file
;;
esac
done
Give it execute permission for root: chmod 0700 /usr/local/sbin/set_sticky.sh
. Then run it at boot time from, say, /etc/rc.local
or whichever RC file is appropriate:
/usr/local/sbin/set_sticky.sh &
Of course, in this example, /tmp/acltest
should disappear on reboot. Otherwise, this should work like a charm.
Best Answer
Each number (also referred to as an octal because it is base8) in that grouping represents 3 bits. If you turn it into binary it makes it a lot easier.
1 = 0 0 1
3 = 0 1 1
5 = 1 0 1
7 = 1 1 1
So if you did 1777, 3777, 5777, or 7777 you would set the sticky bit because the third column would be a 1. However, with 3777, 5777, and 7777 you are additionally setting other bits (SUID for the first column, and SGID for the second column).
Conversely, any other number in that spot (up to the maximum of 7) would not set the sticky bit because the last column wouldn't be a 1 or "on."
2 = 0 1 0
4 = 1 0 0
6 = 1 1 0