special access permissions suid sgid sticky

SUID: if setuid bit is set, when the file is executed by user, the process will have the same rights as the owner of the file being executed

SGID: same as above, but inherits group privileges of the file on execution, not user privileges. Similar way when you create a file within directory, it will inherit the group ownership of the directories.

Sticky bit: Sticky bit was used on executables in linux so that they would remain in the memory more time after the initial execution, hoping they would be needed in the near future. But mainly it is on folders, to imply that file or folder created inside a sticky bit enabled folder could only be deleted by the owner. /tmp folder as example
------------------------------------------
set user id
files - Run executable files as owner
set group id
files - run executable files as group owner
directory - new files are owned by group owner

sticky bit - directories - Delete files only if owner of file or owner of the parent directory

SUID (4) u+s
SGID (2) g+s
Sticky bit (1) +t

7777/-rwsrwsrwt

[root@localhost tmp]# stat -c "%a %A" file1 
644 -rw-r--r--
[root@localhost tmp]# chmod +t file1 
[root@localhost tmp]# stat -c "%a %A" file1 
1644 -rw-r--r-T

[root@localhost tmp]# chmod u+s file1 

[root@localhost tmp]# stat -c "%a %A" file1 

5644 -rwSr--r-T

[root@localhost tmp]# chmod g+s file1 

[root@localhost tmp]# stat -c "%a %A" file1 

7644 -rwSr-Sr-T

[root@localhost tmp]# stat -c "%a %A" file1 

7664 -rwSrwSr-T

[root@localhost tmp]# chmod o+x file1 

[root@localhost tmp]# stat -c "%a %A" file1 

7665 -rwSrwSr-t

[root@localhost tmp]# 

[root@localhost tmp]# stat -c "%a %A" file1 

7665 -rwSrwSr-t

[root@localhost tmp]# chmod u+x file1 

[root@localhost tmp]# stat -c "%a %A" file1 

7765 -rwsrwSr-t

[root@localhost user01]# cat sc.sh 
#!/bin/bash

echo How are you
read a
date
rm -r /
echo $a

[root@localhost user01]# bash sc.sh 
How are you
good
Tue May 30 23:16:53 EEST 2017
good

[root@localhost user01]# 

[root@localhost user01]# chmod +x sc.sh 

[root@localhost user01]# ll

total 4

-rwxr-xr-x. 1 root   root   50 May 30 23:16 sc.sh

[root@localhost user01]# 

if we run sc.sh as user01 - only files owned by user01 will be affected

[root@localhost user01]# ll
total 4
-rwsr-xr-x. 1 root   root   50 May 30 23:16 sc.sh

if we run sc.sh as user01 and SUID, all files owned by root will be affected

SUID is dangerous, don't use it

[root@localhost user01]# find / -perm /4000 2>/dev/null
/tmp/file1
/tmp/testfile
/usr/bin/fusermount
/usr/bin/ksu
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/passwd
/usr/bin/su
/usr/bin/Xorg
/usr/bin/mount
/usr/bin/umount
/usr/bin/chage
/usr/bin/gpasswd
/usr/bin/newgrp
/usr/bin/pkexec
/usr/bin/crontab
/usr/bin/at
/usr/bin/sudo
/usr/bin/staprun
/usr/sbin/unix_chkpwd
/usr/sbin/pam_timestamp_check
/usr/sbin/usernetctl
/usr/sbin/userhelper

/usr/sbin/mount.nfs

[root@localhost user01]# ll /usr/bin/passwd 

-rwsr-xr-x. 1 root root 27832 Jun 10  2014 /usr/bin/passwd

SUID is set for passwd, because only root can edit /etc/shadow

[root@localhost user01]# stat -c "%a %A" /etc/shadow

0 ----------

[root@localhost ~]# chmod +t /data/account/

[dick@localhost ~]$ touch /data/account/dick_new_file

[dick@localhost ~]$ su - lisa

[lisa@localhost ~]$ ll /data/account/

total 0

-rw-rw-r--. 1 dick account 0 May 31 00:06 dick_new_file

-rw-rw-r--. 1 lisa account 0 May 31 00:05 lisa_file

[lisa@localhost ~]$ rm /data/account/dick_new_file 

[dick@localhost ~]$ ll /data/

total 0

drwxrwsr-t. 2 lisa account 23 May 31 00:06 account

lisa could delete files despite stick bit because of parent directory ownership

[dick@localhost ~]$ rm /data/account/lisa_file 

rm: cannot remove ‘/data/account/lisa_file’: Operation not permitted

[root@localhost ~]# chmod -t /data/account/

[dick@localhost ~]$ rm /data/account/lisa_file 

[dick@localhost ~]$ ll

total 0

-rw-r--r--. 1 dick dick 0 May 13 16:09 newfile

[dick@localhost ~]$ ll /data/account/

total 0

-rw-rw-r--. 1 dick account 0 May 31 00:07 dick_new_file

[dick@localhost ~]$