Setuid, setgid, and sticky

After logging on to the system, you will have a default permission when creating a common file or directory. The common file is 644, And the directory file is 755. We all know that this is determined by the umask value. You can run the umask command to check whether the default umask value in linux is 0022. If you want to change the default permission for creating a file, you can directly modify umask, but the general permission is the default permission bit obtained through 777-022. What is this 0 in front of 022? The first 0 is the special permission bit. Let's talk about the setuid, setgid, and sticky special permission bit.

1. suid, set uid: After setuid is added to a program or command (u + s), the owner has the s permission, which means that when any user executes this program, the owner of the process is no longer the initiator, but the owner of the program. The most typical example is the passwd command;

When a common user runs the passwd command to modify his password, the file/etc/passwd is eventually changed.

We know that the/etc/passwd file is a user-managed configuration file, which can be changed only by the root user.

[root@Vmware5 ~]# ls -l /etc/passwd-rw-r--r--. 1 root root 981 Oct 25 01:00 /etc/passwd

According to the general logic, normal users cannot modify the/etc/passwd file, but the special permission bit setuid is added to the passwd command, and the normal account is temporarily changed to root, you can modify the password of your account.

[Root @ Vmware5 ~] # Ls-l/usr/bin/passwd (s is the suid bit)-rwsr-xr-x. 1 root 30768 Feb 22 2012/usr/bin/passwd

Setuid setting method: (in fact, the preceding parameter is u + s)

Chmodu (+ |-) s/path/somefilechmod4664/path/somefile Note: s: indicates that the owner has the execution permission. S: indicates that the owner has no execution permission.

Example:

Add a common user named taokey

[root@Vmware5 ~]# useradd taokey

Copy the/etc/fsatb file to the/tmp directory

[root@Vmware5 ~]# cp /etc/fstab /tmp/[root@Vmware5 ~]# cd /tmp/

View the attributes of the fstab file in the/tmp directory

[root@Vmware5 tmp]# ll fstab-rw-r--r--. 1 root root 899 Oct 25 00:16 fstab

Remove the read permissions of other users

[root@Vmware5 tmp]# chmod o-r fstab[root@Vmware5 tmp]# ll fstab-rw-r-----. 1 root root 899 Oct 25 00:16 fstab

Switch to the common user taokey

[root@Vmware5 tmp]# su - taokey

Run the cat command to check whether the fstab file can be viewed.

[taokey@Vmware5 ~]$ cat/tmp/fstabcat: /tmp/fstab: Permission denied

Because other has removed the r permission, all prompts that cat is denied

Copy the cat command to the/tmp directory to keep the original environment

[root@Vmware5 ~]# cp /bin/cat  /tmp/[taokey@Vmware5 tmp]$ ls-l fstab cat-rwxr-xr-x. 1 root root 45224 Oct 25 00:21 cat-rw-r-----. 1 root root   899 Oct 25 00:16 fstab[taokey@Vmware5 tmp]$ ./catfstab./cat: fstab: Permission denied[taokey@Vmware5 tmp]$ exitlogout

Switch to the root user and add the setuid permission.

[root@Vmware5 tmp]# chmod u+s cat

After adding the s permission bit, switch to the common user taokey to test whether the cat command can be successfully executed.

[root@Vmware5 tmp]# su - taokey[taokey@Vmware5 ~]$ cd/tmp/[taokey@Vmware5 tmp]$ ./catfstab## /etc/fstab# Created by anaconda on Thu Oct 24 23:49:23 2013## Accessible filesystems, by reference, are maintained under '/dev/disk'# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info#UUID=b49ee2b3-75aa-4227-a9ff-5d0d990af0fd /                       ext4    defaults        1 1UUID=3a69daa4-b393-4694-abbb-b856345b376d /bootext4    defaults        1 2UUID=34f85ed8-5f68-4fdc-8aa0-e50d2f9f012e /homeext4    defaults        1 2UUID=95d97c70-9291-499b-ac16-a38508a85e4d swap                    swap    defaults        0 0tmpfs                   /dev/shmtmpfs   defaults        0 0devpts                  /dev/ptsdevpts  gid=5,mode=620  0 0sysfs                   /syssysfs   defaults        0 0proc                    /procproc    defaults        0 0

After switching to a common user, you can run the cat command to view the/tmp/fstab file because the s permission bit is added to the cat command in the tmp directory.

12 [taokey@Vmware5 tmp]$ ll cat -rwsr-xr-x. 1 root root 45224 Oct 25 00:21 cat

Note: It is very dangerous to set the special permission for suid. Do not use it unless you have.

2. sgid, Set id, the owner group has the s permission. This means that when the program is executed, the owner Group of the process is no longer the basic group of the operator himself, it is the group of the program file.

Is there such a problem at work?

O & M and development belong to the same technical department, and users belong to the same group. files are stored in a directory, and O & M personnel and developers can access their files, if you modify the group one by one, it will be a little troublesome. At this time, using sgid will easily solve this problem.

12345678910111213141516171819202122232425 Example: [root@Vmware5 tmp] # usermod -a -G mygrp xen [root@Vmware5 tmp] # usermod -a -G mygrp kvm [root@Vmware5 tmp] # mkdir /tmp/test [root@Vmware5 tmp] # ls -ld /tmp/test/ drwxr-xr-x. 2 root root 4096 Oct 25 00:48 /tmp/test/ [root@Vmware5 tmp] # chmod g+w /tmp/test [root@Vmware5 tmp] # ls -ld /tmp/test/ drwxrwxr-x. 2 root root 4096 Oct 25 00:48 /tmp/test/ [root@Vmware5 tmp] # chown :mygrp /tmp/test [root@Vmware5 tmp] # ls -ld /tmp/test drwxrwxr-x. 2 root mygrp 4096 Oct 25 00:48 /tmp/test [root@Vmware5 ~] # su - xen [xen@Vmware5 ~]$ cd /tmp/test [xen@Vmware5 test ]$ touch a.xen [xen@Vmware5 test ]$ ls -l total 0 -rw-rw-r--. 1 xen xen 0 Oct 25 00:50 a.xen [root@Vmware5 ~] # su - kvm [kvm@Vmware5 ~]$ cd /tmp/test [kvm@Vmware5 test ]$ touch a.kvm [kvm@Vmware5 test ]$ ls -l total 0 -rw-rw-r--. 1 kvm kvm 0 Oct 25 00:51 a.kvm -rw-rw-r--. 1 xen xen 0 Oct 25 00:50 a.xen

The kvm user wants to write to file a. xen created by xen, but is rejected.

12 [kvm@Vmware5 test ]$ echo "hello" >>a.xen - bash : a.xen: Permission denied

We are using root to add a sgid permission bit to the/tmp/test file, and then test it.

123 [root@Vmware5 ~] # chmod g+s /tmp/test [root@Vmware5 ~] # ls -ld /tmp/test drwxrwsr-x. 2 root mygrp 4096 Oct 25 00:51 /tmp/test

Switch to xen normal user

1234567891011121314 [root@Vmware5 ~] # su - xen [xen@Vmware5 test ]$ touch b.xen [xen@Vmware5 test ]$ ll b.xen -rw-rw-r--. 1 xen mygrp 0 Oct 25 01:01 b.xen [root@Vmware5 ~] # su - kvm [kvm@Vmware5 ~]$ echo "hello" >>b.xen [kvm@Vmware5 ~]$ cat b.xen hello [kvm@Vmware5 ~]$ touch b.kvm [root@Vmware5 ~] # su - xen [xen@Vmware5 ~]$ cd /tmp/test/ [xen@Vmware5 test ]$ echo "My name is taoyake." >>b.kvm [xen@Vmware5 test ]$ cat b.kvm My name is taoyake.

This is because the sgid permission bit is set in the/tmp/test file.

But this can not only be successfully written in, but also delete files. We can only delete our own files and do not want other users to delete our files. What should we do at this time?

1234567 For example: [xen@Vmware5 test ]$ rm b.kvm [xen@Vmware5 test ]$ ll total 0 -rw-rw-r--. 1 kvm kvm 0 Oct 25 00:51 a.kvm -rw-rw-r--. 1 xen xen 0 Oct 25 00:50 a.xen -rw-rw-r--. 1 xen mygrp 0 Oct 25 01:01 b.xen

3. At this time, sticky, t, and other are used, which is represented as t.

Chmod o + |-t/path/somefile

123456789101112 Instance operation: [root@Vmware5 ~] # ls -ld /tmp/test drwxrwsr-t. 2 root mygrp 4096 Oct 25 01:10 /tmp/test [xen@Vmware5 test ]$ ls a.kvm a.xen b.xen c.kvm [xen@Vmware5 test ]$ echo "beyond" >>c.kvm [xen@Vmware5 test ]$ cat c.kvm beyond [xen@Vmware5 test ]$ echo "" >c.kvm [xen@Vmware5 test ]$ cat c.kvm [xen@Vmware5 test ]$ rm -rf c.kvm rm : cannot remove `c.kvm': Operation not permitted

You can add or modify files of other users, that is, you cannot delete files of other users. You can delete files created by yourself.

1234567891011 [kvm@Vmware5 test ]$ touch c.kvm [kvm@Vmware5 test ]$ ls a.kvm a.xen b.xen c.kvm [kvm@Vmware5 test ]$ rm c.kvm [kvm@Vmware5 test ]$ ls a.kvm a.xen b.xen [xen@Vmware5 test ]$ ll total 0 -rw-rw-r--. 1 kvm kvm 0 Oct 25 00:51 a.kvm -rw-rw-r--. 1 xen xen 0 Oct 25 00:50 a.xen -rw-rw-r--. 1 xen mygrp 0 Oct 25 01:01 b.xen

This article from the "years in the passage, the glory is still in" blog, please be sure to keep this source http://taokey.blog.51cto.com/4633273/1329992