this is pretty confusing.

SUID != GUID != sticky bit

setuid and setgid (short for „set user ID upon execution“ and „set group ID upon execution“, respectively)[1] are Unix access rights flags that allow users to run an executable with the permissions of the executable’s owner or group respectively and to change behaviour in directories.

They are often used to allow users on a computer system to run programs with temporarily elevated privileges in order to perform a specific task.

If a user is starting a binary program – usually it runs with the rights of that starting-user.

SUID:

if you set SUID bit with:

chmod u+s /path/binary

(SUID BIT WORKS ONLY ON BINARIES – NOT WITH SHELL SCRIPTS!)

it is now run with the rights of the owner (could be root).

This way non-root users are allowed to run mount (to view mountpoints).

find all files and folders with SUID and SGID set

find / -perm /u=s,g=s

find / -perm /u=s,g=s|grep mount
/bin/mount
/bin/umount
/bin/fusermount

ll /bin/mount
-rwsr-xr-x 1 root root 34K Mar 30 2015 /bin/mount

this means: non-root users are allowed to run mount with root priviliges

SGID with directories

you can set SUID (chmod u+s) on folder – but has no effects. (!?)

SGID bit set (chmod g+s) means newly created files are automatically owned by the group – that also owns the directory (inherit, heritage)

mkdir projekt1 projekt2; # create new test directories

su; # become root

addgroup newgroup; # add a new group

chgrp newgroup projekt1; # change group ownership to newgroup

drwxr-xr-x 2 user newgroup 4.0K May 11 15:17 projekt2
                     \_directory is owned by group "newgroup"

chmod g+s projekt1; # set SGID bit on folder

exit; # become previous non-root user again

ll
drwxr-sr-x 2 user newgroup 4.0K May 11 15:01 projekt1
      \_group SGI bit active

cd projekt2;
touch 1 2 3; # create test files

ll; # as you will see the newly created files in these folders are owned by default-group of user (which is also called user)
total 0
-rw-r--r-- 1 user user 0 May 11 15:06 1
-rw-r--r-- 1 user user 0 May 11 15:06 2
-rw-r--r-- 1 user user 0 May 11 15:06 3

cd ../projekt1;

touch 1 2 3; # create test files
ll; # as you will see the newly created files in these folders are owned by newgroup - because of the SGID bit active for the parent folder
total 0
-rw-r--r-- 1 user newgroup 0 May 11 15:06 1
-rw-r--r-- 1 user newgroup 0 May 11 15:06 2
-rw-r--r-- 1 user newgroup 0 May 11 15:06 3

sticky bit

means: only the owner of the file may delete the file.

# can be set with
chmod +t /path/folder

# temporary folder /tmp has sticky bit set
ll /|grep tmp
drwxrwxrwt 9 root root 4.0K May 11 15:24 tmp

use case example:

/tmp = temporary folder

When a directory’s sticky bit is set, the filesystem treats the files in such directories in a special way so only the file’s owner, the directory’s owner, or root user can rename or delete the file. Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of the file’s owner. Typically this is set on the /tmp directory to prevent ordinary users from deleting or moving other users‘ files.

The modern function of the sticky bit was introduced in 4.3BSD in 1986, and is found in most modern Unix-like systems.

[…] the Linux kernel ignores the sticky bit on files. […] When the sticky bit is set on a directory, files in that directory may only be unlinked or renamed by root or the directory owner or the file owner.[4]

src: https://en.wikipedia.org/wiki/Sticky_bit

root@debian:/tmp# ls -lah
total 40K
drwxrwxrwt 9 root root 4.0K May 11 15:26 .
drwxr-xr-x 22 root root 4.0K May 5 15:12 ..
drwxrwxrwt 2 root root 4.0K May 11 14:27 .font-unix
drwxrwxrwt 2 root root 4.0K May 11 14:27 .ICE-unix
drwx------ 2 user user 4.0K May 11 14:27 ssh-iLO5gRFgEBqc
drwx------ 3 root root 4.0K May 11 14:27 systemd-private-105d0c1749f9469b9c0026f910664e81-rtkit-daemon.service-tM9C3z
drwxrwxrwt 2 root root 4.0K May 11 14:27 .Test-unix
-r--r--r-- 1 root root 11 May 11 14:27 .X0-lock
drwxrwxrwt 2 root root 4.0K May 11 14:27 .X11-unix
drwxrwxrwt 2 root root 4.0K May 11 14:27 .XIM-unix

what processes are using tmp right now?

root@debian:/home/user# lsof|grep tmp
kdevtmpfs 12 root cwd DIR 0,5 2980 3 /
kdevtmpfs 12 root rtd DIR 0,5 2980 3 /
kdevtmpfs 12 root txt unknown /proc/12/exe
Xorg 948 root 1u unix 0xf207bcc0 0t0 12931 @/tmp/.X11-unix/X0
...
Xorg 948 root 29u unix 0xf46ae0c0 0t0 14533 @/tmp/.X11-unix/X0
Xorg 948 root 30u unix 0xf3b5ba00 0t0 14563 @/tmp/.X11-unix/X0
x-session 986 user 9u unix 0xf3aaee80 0t0 13430 @/tmp/.ICE-unix/986
...
gmain 986 1024 user 10u unix 0xf3aaf140 0t0 13431 /tmp/.ICE-unix/986
gmain 986 1024 user 18u unix 0xf312e640 0t0 14012 @/tmp/.ICE-unix/986
ssh-agent 1006 user 3u unix 0xf3d85680 0t0 13390 /tmp/ssh-iLO5gRFgEBqc/agent.986
dbus-daem 1010 user 4u unix 0xf3d85100 0t0 13404 @/tmp/dbus-ahR6nEGGhS
dbus-daem 1010 user 8u unix 0xf3aaf980 0t0 13414 @/tmp/dbus-ahR6nEGGhS
...
0 user 35u unix 0xf3bcb0c0 0t0 14636 @/tmp/dbus-ahR6nEGGhS
bash 1780 user cwd DIR 8,1 4096 524289 /tmp

What i find a little confusing:

or maybe i get something wrong here.

if a user starts process /bin/processX

and x is creates files under /tmp/processX_temp_file

the ownership would probably be that of the user.

ll /tmp
userX groupX /tmp/processX_temp_file

so if chmod+t or not… other userY can NOT delete those files anyway? (unless userY would be in same group as userX namely groupX – but even than – group rights would have to set chmod g+rwx to allow file-deletion.)

end of story.

more stuff

if possibly – keep it the UNIX „small and beautiful“ simplify way…

depending on the filesystem in use (ext2, ext4) more file-system confusion can be done:

change file attributes on a Linux file system – chattr.man.txt

list file attributes on a Linux second extended file system – lsattr.man.txt

have phun!

admin