sticky bit

in Linux, the sticky bit is used on 2 levels : directories and files.

Directories

Set the sticky bit so that a user can only delete files which belongs to him.
For example, /tmp have 777 permissions, but you maybe don’t want users to be able to delete all the files in that folder (which is why /tmp has the sticky bit, by the way)

So let’s have a look : first we have a 777 directory and files with different users

[root@sandbox ~]# ls -ld /test
drwxrwxrwx 2 777 root 4096 Jun 11 08:31 /test
[root@sandbox ~]# ls -l /test
-rw-rw-r-- 1 guest guest 0 Jun 11 08:32 guest
-rw-r--r-- 1 hdfs hadoop 0 Jun 11 08:32 hdfs
-rw-r--r-- 1 hdfs hadoop 0 Jun 11 08:32 hdfs2
-rw-rw-r-- 1 hue hue 0 Jun 11 08:32 hue

As expected, hue user can delete hdfs file :

[root@sandbox ~]# su - hue -c "rm -f /test/hdfs2"

Now let’s set the sticky bit to the directory and retry to delete another user file

[root@sandbox ~]# chmod +t /test
[root@sandbox ~]# su - hue -c "rm -f /test/hdfs"
rm: cannot remove `/test/hdfs': Operation not permitted

You’ll notice the “t” in the permissions list :

[root@sandbox ~]# ls -ld /test
drwxrwxrwt 2 777 root 4096 Jun 11 08:51 /test

Files

The sticky bit itself isn’t used (or in very specific cases / os). We rather talk about setuid, which is generally called sticky bit as a misnomer.

When a file belongs to a user, it can also be set as setuid, meaning it’ll be executed with file owner rights, not the launcher.
As an example, passwd is setuid root (it is setuid and belongs to root): that means if launch it under “guest“, it will be executed as root so that it can write in /etc/passwd (which is writable only by root)

You can setuid with

chmod +s /etc/passwd

So, what do you think ?

  • Time limit is exhausted. Please reload CAPTCHA.