In this article, we discuss about the SUID, SGID, and sticky bit.
when you look around in your file system you see 's' and 't' bit. These are the special file permissions for the files.
[sunil@server ~]$ ls -ld /tmp
drwxrwxrwt 6 root root 4096 Mar 23 07:14 /tmp
[sunil@server ~]$ which passwd
/usr/bin/passwd
[sunil@server ~]$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 22960 Jul 17 2006 /usr/bin/passwd
When special mode of the file needs to set, then we use below values;
SUID=4
SGID=2
Sticky bit=1
Let us discuss, in detail
SUID(Set-User-Id):
when user executes a file, the process by default has the same permissions as the user. In other words process inherits his default group and user identifications.
By setting SUID, process doesn't use the user's identification but the user identification of the file owner.
[sunil@server ~]$ ls -l /etc/passwd /etc/shadow /usr/bin/passwd
-rw-r--r-- 1 root root 1725 Mar 23 07:27 /etc/passwd
-r-------- 1 root root 1214 Mar 23 07:27 /etc/shadow
-rwsr-xr-x 1 root root 22960 Jul 17 2006 /usr/bin/passwd
From above we observe that 'passwd' is readable by all, but shadow is un-readable by group and other users.
Normal user wants to change the password, he can by running /usr/bin/passwd which have a special permission mode that lets users update sensitive system files like /etc/shadow --something they can't do directly with an editor. True fact of 'passwd ' command.
[sunil@server ~]$ ls -ld /usr/bin/passwd
-rwsr-xr-x 1 root root 22960 Jul 17 2006 /usr/bin/passwd
Observe letter 's' which is SUID, which sets a process have the privileges of the owner of the file during running instance.
Thus when a non privileged user executes passwd, the effective UID of the process is not the user's, but of root's.
[sunil@server ~]$ id -a
uid=502(sunil) gid=502(sunil) groups=502(sunil)
Take a look at below script.
[sunil@server ~]$ cat reids.pl
#!/usr/bin/perl
# printing Real UID
print "RUID: $<\n";
# printing Real GID
print "RGID: $(\n";
# printing Effective UID
print "EUID: $>\n";
# printing Effective GID
print "EGID: $)\n";
The file is owned by sunil, and observe file permissions.
[sunil@server ~]$ ls -l reids.pl
-rwxrwxr-x 1 sunil sunil 187 Mar 23 07:56 reids.pl
When you run the script you will see that the process that runs it gets your user-ID and your group-ID:
[sunil@server ~]$ ./reids.pl
RUID: 502
RGID: 502 502
EUID: 502
EGID: 502 502
Now changing owner ship to another user.
[root@server ~]# chown gee /home/sunil/reids.pl
[root@server ~]# ls -l /home/sunil/reids.pl
-rwxrwxr-x 1 gee sunil 200 Mar 23 07:32 /home/sunil/reids.pl
Running script again,
[sunil@server ~]$ ./reids.pl
RUID: 502
RGID: 502 502
EUID: 502
EGID: 502 502
Output of the program depends only on the user that runs it and not the one who owns the file.
SUID permission:
[root@server ~]# chmod 4775 /home/sunil/reids.pl
[root@server ~]# ls -l /home/sunil/reids.pl
-rwsrwxr-x 1 gee sunil 187 Mar 23 07:56 /home/sunil/reids.pl
Once 's' bit is set, file is executed under the UID of the user that owns the file rather than user who is ececuting the file.
so, even when sunil runs the file, EUID=103 which is not sunil's.
[sunil@server ~]$ ./reids.pl
RUID: 502
RGID: 502 502
EUID: 503
EGID: 502 502
SGID(Set-Group-Id):
Similar to SUID, except that a program with SGID set allows the user to have the same power as the group.
Created two users(sunil,gee), who shares a common directory(/admin) with write permission, with group ownership(admin).
[root@server ~]# groupadd admin
[root@server ~]# chgrp admin /admin/
[root@server ~]# mkdir /admin
[root@server ~]# chmod 775 /admin/
[sunil@server ~]$ ls -ld /admin/
drwxrwxr-x 2 root admin 4096 Mar 23 08:27 /admin/
Adding, users to admin share.
[root@server ~]# usermod -G admin sunil
[root@server ~]# usermod -G admin gee
Login with sunil credentails and create file in /admin directory.
[sunil@server admin]$ pwd
/admin
[sunil@server admin]$ ls -l
total 0
-rw-rw-r-- 1 sunil sunil 0 Mar 23 08:39 sun-beforesgid
Login with user gee and create a file in /admin directory.
[gee@server admin]$ pwd
/admin
[gee@server admin]$ ls -l
total 0
-rw-rw-r-- 1 gee gee 0 Mar 23 08:40 gee-beforesgid
-rw-rw-r-- 1 sunil sunil 0 Mar 23 08:39 sun-beforesgid
SGID bit is not set, when files are created in /admin, the group for the file is user's primary GID.
Setting SGID bit, and login as sunil and create file.
[root@server ~]# chmod 2775 /admin/
[root@server ~]# ls -ld /admin/
drwxrwsr-x 2 root admin 4096 Mar 23 08:27 /admin/
[sunil@server admin]$ ls -l
total 0
-rw-rw-r-- 1 gee admin 0 Mar 23 08:41 gee-aftersgid
-rw-rw-r-- 1 gee gee 0 Mar 23 08:40 gee-beforesgid
-rw-rw-r-- 1 sunil admin 0 Mar 23 08:41 sun-aftersgid
-rw-rw-r-- 1 sunil sunil 0 Mar 23 08:39 sun-beforesgid
Notice the group ownership for " *-aftersgid ". It inherits group permission from the parent directory
"Enabling SGID on a directory is extremely useful when you have a group of users with different primary groups working on the same set of files."
Sticky bit:
Everyone can read,write and access the directory.The 't' indicates that only the user (root and owner of the directory,of course) that created a file in this directory can delete that file.
One user could remove another user's file
Eg:[sunil@server admin]$ ls -l
-rw-rw-r-- 1 gee admin 0 Mar 23 08:41 gee-aftersgid
-rw-rw-r-- 1 gee admin 0 Mar 23 08:48 gee-afterstickybit
-rw-rw-r-- 1 gee gee 0 Mar 23 08:40 gee-beforesgid
-rw-rw-r-- 1 gee admin 0 Mar 23 08:48 gee-beforestickybit
-rw-rw-r-- 1 sunil admin 0 Mar 23 08:41 sun-aftersgid
-rw-rw-r-- 1 sunil admin 0 Mar 23 08:48 sun-afterstickybit
-rw-rw-r-- 1 sunil sunil 0 Mar 23 08:39 sun-beforesgid
-rw-rw-r-- 1 sunil admin 0 Mar 23 08:48 sun-beforestickybit
[sunil@server admin]$ rm gee-beforestickybit
[sunil@server admin]$ ls gee-beforestickybit
ls: gee-beforestickybit: No such file or directory
[sunil@server admin]$
Sunil was able to remove file. In order to prevent we use sticky bit.
[root@server ~]# chmod +t /admin/
[sunil@server ~]$ ls -ld /admin
drwxrwsr-t 2 root admin 4096 Mar 23 08:27 /admin/
Here it throws the below error, while removing the file.
[sunil@server admin]$ rm gee-afterstickybit
rm: cannot remove `gee-afterstickybit': Operation not permitted
Hope by this article you would have understood about the importance of advance linux file permissions.
when you look around in your file system you see 's' and 't' bit. These are the special file permissions for the files.
[sunil@server ~]$ ls -ld /tmp
drwxrwxrwt 6 root root 4096 Mar 23 07:14 /tmp
[sunil@server ~]$ which passwd
/usr/bin/passwd
[sunil@server ~]$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 22960 Jul 17 2006 /usr/bin/passwd
When special mode of the file needs to set, then we use below values;
SUID=4
SGID=2
Sticky bit=1
Let us discuss, in detail
SUID(Set-User-Id):
when user executes a file, the process by default has the same permissions as the user. In other words process inherits his default group and user identifications.
By setting SUID, process doesn't use the user's identification but the user identification of the file owner.
[sunil@server ~]$ ls -l /etc/passwd /etc/shadow /usr/bin/passwd
-rw-r--r-- 1 root root 1725 Mar 23 07:27 /etc/passwd
-r-------- 1 root root 1214 Mar 23 07:27 /etc/shadow
-rwsr-xr-x 1 root root 22960 Jul 17 2006 /usr/bin/passwd
From above we observe that 'passwd' is readable by all, but shadow is un-readable by group and other users.
Normal user wants to change the password, he can by running /usr/bin/passwd which have a special permission mode that lets users update sensitive system files like /etc/shadow --something they can't do directly with an editor. True fact of 'passwd ' command.
[sunil@server ~]$ ls -ld /usr/bin/passwd
-rwsr-xr-x 1 root root 22960 Jul 17 2006 /usr/bin/passwd
Observe letter 's' which is SUID, which sets a process have the privileges of the owner of the file during running instance.
Thus when a non privileged user executes passwd, the effective UID of the process is not the user's, but of root's.
[sunil@server ~]$ id -a
uid=502(sunil) gid=502(sunil) groups=502(sunil)
Take a look at below script.
[sunil@server ~]$ cat reids.pl
#!/usr/bin/perl
# printing Real UID
print "RUID: $<\n";
# printing Real GID
print "RGID: $(\n";
# printing Effective UID
print "EUID: $>\n";
# printing Effective GID
print "EGID: $)\n";
The file is owned by sunil, and observe file permissions.
[sunil@server ~]$ ls -l reids.pl
-rwxrwxr-x 1 sunil sunil 187 Mar 23 07:56 reids.pl
When you run the script you will see that the process that runs it gets your user-ID and your group-ID:
[sunil@server ~]$ ./reids.pl
RUID: 502
RGID: 502 502
EUID: 502
EGID: 502 502
Now changing owner ship to another user.
[root@server ~]# chown gee /home/sunil/reids.pl
[root@server ~]# ls -l /home/sunil/reids.pl
-rwxrwxr-x 1 gee sunil 200 Mar 23 07:32 /home/sunil/reids.pl
Running script again,
[sunil@server ~]$ ./reids.pl
RUID: 502
RGID: 502 502
EUID: 502
EGID: 502 502
Output of the program depends only on the user that runs it and not the one who owns the file.
SUID permission:
[root@server ~]# chmod 4775 /home/sunil/reids.pl
[root@server ~]# ls -l /home/sunil/reids.pl
-rwsrwxr-x 1 gee sunil 187 Mar 23 07:56 /home/sunil/reids.pl
Once 's' bit is set, file is executed under the UID of the user that owns the file rather than user who is ececuting the file.
so, even when sunil runs the file, EUID=103 which is not sunil's.
[sunil@server ~]$ ./reids.pl
RUID: 502
RGID: 502 502
EUID: 503
EGID: 502 502
SGID(Set-Group-Id):
Similar to SUID, except that a program with SGID set allows the user to have the same power as the group.
Created two users(sunil,gee), who shares a common directory(/admin) with write permission, with group ownership(admin).
[root@server ~]# groupadd admin
[root@server ~]# chgrp admin /admin/
[root@server ~]# mkdir /admin
[root@server ~]# chmod 775 /admin/
[sunil@server ~]$ ls -ld /admin/
drwxrwxr-x 2 root admin 4096 Mar 23 08:27 /admin/
Adding, users to admin share.
[root@server ~]# usermod -G admin sunil
[root@server ~]# usermod -G admin gee
Login with sunil credentails and create file in /admin directory.
[sunil@server admin]$ pwd
/admin
[sunil@server admin]$ ls -l
total 0
-rw-rw-r-- 1 sunil sunil 0 Mar 23 08:39 sun-beforesgid
Login with user gee and create a file in /admin directory.
[gee@server admin]$ pwd
/admin
[gee@server admin]$ ls -l
total 0
-rw-rw-r-- 1 gee gee 0 Mar 23 08:40 gee-beforesgid
-rw-rw-r-- 1 sunil sunil 0 Mar 23 08:39 sun-beforesgid
SGID bit is not set, when files are created in /admin, the group for the file is user's primary GID.
Setting SGID bit, and login as sunil and create file.
[root@server ~]# chmod 2775 /admin/
[root@server ~]# ls -ld /admin/
drwxrwsr-x 2 root admin 4096 Mar 23 08:27 /admin/
[sunil@server admin]$ ls -l
total 0
-rw-rw-r-- 1 gee admin 0 Mar 23 08:41 gee-aftersgid
-rw-rw-r-- 1 gee gee 0 Mar 23 08:40 gee-beforesgid
-rw-rw-r-- 1 sunil admin 0 Mar 23 08:41 sun-aftersgid
-rw-rw-r-- 1 sunil sunil 0 Mar 23 08:39 sun-beforesgid
Notice the group ownership for " *-aftersgid ". It inherits group permission from the parent directory
"Enabling SGID on a directory is extremely useful when you have a group of users with different primary groups working on the same set of files."
Sticky bit:
Everyone can read,write and access the directory.The 't' indicates that only the user (root and owner of the directory,of course) that created a file in this directory can delete that file.
One user could remove another user's file
Eg:[sunil@server admin]$ ls -l
-rw-rw-r-- 1 gee admin 0 Mar 23 08:41 gee-aftersgid
-rw-rw-r-- 1 gee admin 0 Mar 23 08:48 gee-afterstickybit
-rw-rw-r-- 1 gee gee 0 Mar 23 08:40 gee-beforesgid
-rw-rw-r-- 1 gee admin 0 Mar 23 08:48 gee-beforestickybit
-rw-rw-r-- 1 sunil admin 0 Mar 23 08:41 sun-aftersgid
-rw-rw-r-- 1 sunil admin 0 Mar 23 08:48 sun-afterstickybit
-rw-rw-r-- 1 sunil sunil 0 Mar 23 08:39 sun-beforesgid
-rw-rw-r-- 1 sunil admin 0 Mar 23 08:48 sun-beforestickybit
[sunil@server admin]$ rm gee-beforestickybit
[sunil@server admin]$ ls gee-beforestickybit
ls: gee-beforestickybit: No such file or directory
[sunil@server admin]$
Sunil was able to remove file. In order to prevent we use sticky bit.
[root@server ~]# chmod +t /admin/
[sunil@server ~]$ ls -ld /admin
drwxrwsr-t 2 root admin 4096 Mar 23 08:27 /admin/
Here it throws the below error, while removing the file.
[sunil@server admin]$ rm gee-afterstickybit
rm: cannot remove `gee-afterstickybit': Operation not permitted
Hope by this article you would have understood about the importance of advance linux file permissions.
No comments:
Post a Comment