Linux Permissions SUID, SGID and Sticky Bit Concept Explained with Examples

In this article, we are going to discuss on Linux Permissions SUID, SGID and Sticky Bit Concept Explained with Examples. Before we discuss Special Linux Permissions let’s have look at basic Linux Permissions. In Linux, There are three types of the permission we can apply i.e. Read, Write & Execute. And each file and directories comes with three sets of Users i.e. User (Owner), Group and Others. We can change permission by using chmod command.

Linux Permissions SUID, SGID and Sticky Bit Concept Explained with Examples

Linux Permissions SUID, SGID and Sticky Bit Concept Explained with Examples

Linux Permissions SUID, SGID and Sticky Bit Concept Explained with Examples:

SUID (Super User ID)

SUID Stands for Super User ID. We know that root is the Super User in Linux and have all the rights to do administrative tasks but have you noticed that normal user also can do some administrative tasks such as reset the Password and as we know that by resetting the password two files getting updated i.e. /etc/passwd and /etc/shadow which is only can be done by root user. Let’s take another example i.e. Normal user can use the ping command to check network connectivity. Now let’s Understand what is the use of SUID. First of all, SUID should be applied to a binary file or to a script and we can apply SUID from root user only using the chmod command. We are applying SUID to any binary file or script means we are allowing that binary file to execute in any logged in user as an owner of that file. Means if i run the ping command by logging in with a normal user i.e. user1 still it will run as the root user only. Let’s take an example to understand the concept properly. SUID alphabetically identified by letter “s” and Numerically Identified by “4“.

Logging as a normal user i.e. user1 and try to use the ping command to check the connectivity.

[user1@localhost ~]$ whoami   # To check currently Logged in User
user1
[user1@localhost ~]$ ping -c 3 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.027 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.042 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.042 ms

--- localhost ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.027/0.037/0.042/0.007 ms

As we can see on the above sample output we able to use ping command in normal user. The reason behind that is SUID special permission is applied to ping binary file. we can use ls -l command to check the permission.

First, check the path of ping binary file by which command and then check the permission of that file by using ls -l command.

[root@localhost ~]# which ping   # Checking the Path of the File
/bin/ping
[root@localhost ~]# ls -l /bin/ping   # Checking the Permission of the File
-rwsr-xr-x. 1 root root 40760 Sep 26  2013 /bin/ping

As per Sample output above Owner of the ping, binary is root (Highlighted in Red Color) and belongs to group root (Highlighted in Skyblue Color) and has -rwsr-xr-x permission. Here “s” is nothing but SUID which is applied to the Owner. So whenever we run ping command in normal user it still runs as an owner of the file and has nothing concerned with that normal user.

To apply for SUID Special Permission you can use the chmod command. There are two ways by which we can apply for SUID permission i.e. Alphabetically and Numerically. Follow the sample output below.

Apply SUID Alphabetically :

[root@localhost ~]# chmod u+s /bin/ping   # Applying SUID Permission to ping binary file Alphabetically
[root@localhost ~]# ls -l /bin/ping
-rwsr-xr-x. 1 root root 40760 Sep 26  2013 /bin/ping

Apply SUID Numerically :

[root@localhost ~]# chmod 4755 /bin/ping   # Applying SUID Permission Numerically
[root@localhost ~]# ls -l /bin/ping
-rwsr-xr-x. 1 root root 40760 Sep 26  2013 /bin/ping

Let’s check what will happen if we remove the SUID permission from ping binary file.

[root@localhost ~]# chmod u-s /bin/ping   # Removing SUID Permission
[root@localhost ~]# ls -l /bin/ping
-rwxr-xr-x. 1 root root 40760 Sep 26  2013 /bin/ping

To remove SUID numerically add “0” at the beginning with whatever the permission of your files. For example, Here my file has full access for Owner and Read and Execute permission for Group and Others So the command would be as shown below.

[root@localhost ~]# chmod 0755 /bin/ping   # Removing SUID by Numerically

Where :

0 – to remove SUID permission
755  – is the permission of the file

As you can see above SUID permission has been removed, Now let’s logging as a normal user and check by running ping command.

[user1@localhost ~]$ ping -c 3 localhost
ping: icmp open socket: Operation not permitted

It’s not working as it doesn’t have SUID Permission.

Also Read:- Complete Unix Commands And Basic Linux Commands With Examples For Beginners

SGID (Super Group ID)

SGID  stands for Super Group ID. This special Linux permission is the same as SUID with little difference. The difference is when we apply SUID means that belongs to a particular user and a particular user will be affected by that permission but when we apply SGID permission then that will effect to a Group and Group means Multiple users. Here below I explained an example related to an SGID so that you will find more easy to understand the concept. SGID alphabetically identified by letter “s” and Numerically Identified by “2“.

Let’s say I have two users i.e. member1 and member2 and a group named admins. The users member1 and member2 are the members of group admins.

[root@localhost ~]# cat /etc/group | grep admins
admins:x:502:member1,member2

Now let’s create a directory named database in / and give appropriate permission. Here I am giving rwx to userrwx to group and rx to others Follow the sample output.

[root@localhost ~]# mkdir /database   # Creating a Directory
[root@localhost ~]# chmod 775 /database/   # Giving Permissions
[root@localhost ~]# ls -l /
total 110
dr-xr-xr-x.   2 root root  4096 Apr  8 04:32 bin
dr-xr-xr-x.   5 root root  1024 Apr  8  2017 boot
drwxrwxr-x.   2 root root  4096 Apr  8 07:14 data
drwxrwxr-x.   2 root root  4096 Apr  8 07:19 database
drwxr-xr-x.  18 root root  3960 Apr  8 03:15 dev
drwxr-xr-x. 101 root root 12288 Apr  8 07:18 etc
drwxr-xr-x.   9 root root  4096 Apr  8 07:17 home

I am going to change the group ownership of the directory by using chgrp command So that the owner of the directory would be root and admins.

[root@localhost ~]# chgrp admins /database/   # Changing Group Ownership
[root@localhost ~]# ls -l /
total 110
dr-xr-xr-x.   2 root root    4096 Apr  8 04:32 bin
dr-xr-xr-x.   5 root root    1024 Apr  8  2017 boot
drwxrwxr-x.   2 root root    4096 Apr  8 07:14 data
drwxrwxr-x.   2 root admins  4096 Apr  8 07:19 database
drwxr-xr-x.  18 root root    3960 Apr  8 03:15 dev
drwxr-xr-x. 101 root root   12288 Apr  8 07:18 etc
drwxr-xr-x.   9 root root    4096 Apr  8 07:17 home

Now let’s apply SGID Special Linux Permissions to the directory using the chmod command.

After applying for the SGID permission you will able to notice a letter “s” (Highlighted in orange color) on group permission section on the directory.

[root@localhost ~]# chmod g+s /database/   # Applying SGID Permission
[root@localhost ~]# ls -l /
total 110
dr-xr-xr-x.   2 root root    4096 Apr  8 04:32 bin
dr-xr-xr-x.   5 root root    1024 Apr  8  2017 boot
drwxrwxr-x.   2 root root    4096 Apr  8 07:14 data
drwxrwsr-x.   2 root admins  4096 Apr  8 07:19 database
drwxr-xr-x.  18 root root    3960 Apr  8 03:15 dev
drwxr-xr-x. 101 root root   12288 Apr  8 07:18 etc
drwxr-xr-x.   9 root root    4096 Apr  8 07:17 home

Now login by any normal user i.e. member1 and create a file in /database.

[root@localhost ~]# su - member1
[member1@localhost ~]$ whoami
member1
[member1@localhost ~]$ cd /database/
[member1@localhost database]$ touch file1
# A you can see below the owner of the file is member1 and admins
[member1@localhost database]$ ls -l
total 0
-rw-rw-r--. 1 member1 admins 0 Apr  8 07:29 file1     

Now let’s login through a different user that is member2 and try to edit that file.

[root@localhost ~]# su - member2
[member2@localhost ~]$ whoami
member2
[member2@localhost ~]$ cd /database/
[member2@localhost database]$ vi file1

[member2@localhost database]$ cat file1 
Welcome to Itsmarttricks

As you can see on the output above we are able to successfully edit the file by logging in by user “member2“which was created by user “member1” because “member2” is also a member of group “admins“.

Like that you can create a file in /database directory by logging in member2 and it is possible to edit that file by logging in member1.

So the main purpose of SGID is if a team is working on some data which needs to edit or executed by all team members then in that case you can use SGID.

To remove SGID follow below commands :

chmod g-s /database/   # Remove SGID Alphabetically

chmod 0775 /database   # Remove SGID Numerically

Also Read:- Best Yum Command With Examples A Package Manager In Rhel/Centos/Fedora

Sticky Bit :

Sticky bit Special Linux Permissions is very simple to learn and understand as compared to SUID and SGID. Suppose you stored some data in some directory let’s say in /database directory which is accessible to everyone, which means your data is on high risk and anyone can delete your data. To avoid such situation you can use Sticky Bit permission. Sticky Bit alphabetically identified by letter “t” and Numerically Identified by “1“.

What is the use of Sticky Bit?

Let’s take a scenario that we have a directory i.e. /database to which everyone has full access. suppose user1 creates a file named user1.txt. as all users have full access to the directory anyone can come and delete the file created by user1 as we have no control over it. So to avoid such situation we can apply Sticky Bit special Linux Permissions to that directory by which user1 (Owner of user1.txt file) only able to delete or edit that file even after everyone has full access to the /database directory.

Such a situation is possible in a large organization where all users allowed one share drive to store data so, In that case, we can apply Sticky Bit.

Practical :

Create a directory named /database and give full access to everyone.

[root@localhost ~]# mkdir /database
[root@localhost ~]# chmod 777 /database/
[root@localhost ~]# ls -l /
total 102
dr-xr-xr-x.   2 root root  4096 Apr  8 04:32 bin
dr-xr-xr-x.   5 root root  1024 Apr  8  2017 boot
drwxrwxrwx.   2 root root  4096 Apr  8 05:19 database
drwxr-xr-x.  18 root root  3960 Apr  8 03:15 dev
drwxr-xr-x. 101 root root 12288 Apr  8 05:17 etc
drwxr-xr-x.   6 root root  4096 Apr  8 05:17 home
dr-xr-xr-x.  10 root root  4096 Apr  8  2017 lib
dr-xr-xr-x.   9 root root 12288 Apr  8 04:31 lib64

Now apply sticky bit permission to it. you can apply Sticky permission in two ways :

Alphabetical Way :

[root@localhost ~]# chmod +t /database/

[root@localhost ~]# chmod o+t /database/

Numerical Way :

[root@localhost ~]# chmod 1777 /database/

After applied Sticky Bit you will notice the letter “t” on other permission section of /database

[root@localhost ~]# ls -l /
total 102
dr-xr-xr-x.   2 root root  4096 Apr  8 04:32 bin
dr-xr-xr-x.   5 root root  1024 Apr  8  2017 boot
drwxrwxrwt.   2 root root  4096 Apr  8 05:19 database
drwxr-xr-x.  18 root root  3960 Apr  8 03:15 dev
drwxr-xr-x. 101 root root 12288 Apr  8 05:17 etc
drwxr-xr-x.   6 root root  4096 Apr  8 05:17 home
dr-xr-xr-x.  10 root root  4096 Apr  8  2017 lib
dr-xr-xr-x.   9 root root 12288 Apr  8 04:31 lib64

Now log in as user1 and create a file in /database and check the permission.

[root@localhost ~]# su - user1
[user1@localhost ~]$ whoami
user1


[user1@localhost ~]$ cd /database/
[user1@localhost database]$ touch user1.txt
[user1@localhost database]$ ls -l
total 0
-rw-rw-r--. 1 user1 user1 0 Apr  8 05:22 user1.txt

As you can see above the owner of user1.txt user1.

Now login by user2 and try to delete the file created by user1.

[root@localhost ~]# su - user2
[user2@localhost ~]$ whoami
user2

[user2@localhost ~]$ cd /database/
[user2@localhost database]$ ls
user1.txt
[user2@localhost database]$ rm user1.txt 
rm: remove write-protected regular empty file `user1.txt'? y
rm: cannot remove `user1.txt': Operation not permitted

So as you can see in the output above user2 is unable to delete the file as we have applied Sticky bit to it.

chmod o-t /database/   # Remove Sticky Bit Alphabetically

chmod 0777 /database   # Remove Sticky Bit Numerically

That’s all, In this article, we have explained Linux SUID, SGID and Sticky Bit Concept Explained with Examples. I hope you enjoy this article. If you like this article, then just share it. If you have any questions about this article, please comment.

Share this:

Mangesh Dhulap

This is Mangesh Dhulap the Founder and Editor of IT SMART TRICKS have 6+ years of Industrial Experience. We expect from our visitors to like, share, and comment on our posts.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.