Linux文件特殊权限之set位权限和粘滞位权限

http://www.it165.net/os/html/201403/7460.html

进程访问文件时的权限匹配机制：进程的发起者，作为进程的属主；而进程属主所属的基本组作为进程的属组；

进程在确定对文件的访问权限的时候，首先会去查看进程的属主和文件的属主是否一样，若一样，则运用该文件属主的权限，否则则检查进程的属主所属的组(用户可属于多个组)，是否有其中之一与文件的属组匹配，若有，则运用该文件属组的权限，否则，则运用其他权限。

默认情况下，在Linux系统中，我们创建的目录的权限是755，文件的权限是644，想必大家都知道这是umask的功劳。出于文件系统安全性的考虑，umask的默认权限掩码是0022。当然，我们也可通过变量赋值的方式设置自己的默认权限掩码，不过一般我们没必要这样做。

创建目录的默认权限=777-022=755；创建目录的默认权限=666-022=644

此时，我想大家一定想知道，为啥我之前说umask默认权限掩码是0022，怎么在运算的时候，却写的是022，是吧？别着急，马上为您揭晓答案

因为(从左往右数)第一个0表示的是特殊权限位，我们通常所说的多指：suid,sgid,sticky

这三种特殊权限位的作用，应用场景，及使用方法我会在下面为大家详细描述

 

1.set位权限(suid,sgid)

set位权限有两部分组成：suid和sgid,分别对应可执行行文件属主和属组的身份

suid位权限的表现形式：s或S 也可用数字4表示

x: s -: S 若该文件之前，用户已有可执行权限,那么设置了suid位权限后，将在该文件属主的可执行权限位上，显示为s；

否则显示为S

sgid位权限的表现形式：s或S 也可用数字2表示

x: s -: S 若该文件之前，属组已有可执行权限,那么设置了sgid位权限后，将在该文件属组的可执行权限位上，显示为s；

否则显示为S

作用：设置完set权限后，任何用户在执行此可执行文件的过程中，将获得该文件属主、属组的身份。

suid权限位的设定：chmod u+s File ... 或chmod 4nnn filename...

sgid权限位的设定：chmod g+s File ... 或chmod 2nnn filename...

其中nnn：分别表示属主属组其他用户对该文件的权限

权限及对应的数值表示方法： r:4;w:2;x:1

注：一般来说，我们对能可执行文件设置suid和sgid权限，但考虑到特殊权限在工作中的实际意义，我将在有意义的应用环境中为大家讲解。

 

实例演示：

应用场景：使普通用户有权限执行一些特殊的程序或脚本，进而完成日常的工作任务，因此，我们通常使用suid对可执行文件，设置权限。下面的例子仅用于展示suid的作用

(1)创建测试文件

1. [root@Liu ~]# cp /bin/cat /tmp/

2. [root@Liu ~]# cp /etc/fstab /tmp/

3. [root@Liu ~]# chmod og= /tmp/fstab

4. [root@Liu ~]# ll /tmp/fstab

5. -rw------- 1 root root 921 Mar 12 00:18 /tmp/fstab

6. [root@Liu ~]# ll /tmp/cat

7. -rwxr-xr-x 1 root root 48568 Mar 12 00:18 /tmp/cat

(2)添加用户hadoop

1. [root@Liu ~]# useradd hadoop

(3)并切换至用户hadoop

1. [root@Liu ~]# su - hadoop

注：su username和su - username的区别

(4)执行/tmp/cat命令，看是否能查看/tmp/fstab文件中的内容

1. [hadoop@Liu ~]$ /tmp/cat/tmp/fstab

2. /tmp/cat: /tmp/fstab: Permission denied

很明显，权限拒绝，即hadoop无权查看/tmp/fstab文件中的内容

 

眼见为实，现在，我将为/tmp/cat命令设置suid权限，让您一睹suid的风采...

(5)退出hadoop用户，并以root身份为/tmp/cat设置suid权限

1. [hadoop@Liu ~]$exit

2. logout

3. [root@Liu ~]# chmod u+s /tmp/cat

(6)此时，我们再切换至hadoop用户，执行/tmp/cat命令，看会出现啥样的效果

01. [root@Liu ~]# su - hadoop

02. [hadoop@Liu ~]$ /tmp/cat/tmp/fstab

03. #

04. # /etc/fstab

05. # Created by anaconda on Wed Feb 12 16:34:52 2014

06. #

07. # Accessible filesystems, by reference, are maintained under '/dev/disk'

08. # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info

09. #

10. /dev/mapper/vg0-root    /                       ext4    defaults        1 1

11. UUID=5d7ceb50-e9cf-48f2-abe5-6da1b536143e /boot                   ext4    defaults        1 2

12. /dev/mapper/vg0-usr     /usr                    ext4    defaults        1 2

13. /dev/mapper/vg0-var     /var                    ext4    defaults        1 2

14. /dev/mapper/vg0-swap    swap                    swap    defaults        0 0

15. tmpfs                   /dev/shm                tmpfs   defaults        0 0

16. devpts                  /dev/pts                devpts  gid=5,mode=620  0 0

17. sysfs                   /sys                    sysfs   defaults        0 0

18. proc                    /proc                   proc    defaults        0 0

简直太神奇了，普通用户hadoop，居然可以查看属主和属组皆为root用户的文件了...

 

为帮助您加深记忆，那就让我们对比一下，设置suid权限位前后，可执行程序/tmp/cat的权限变化吧...

(1)退出hadoop用户,并切换至root用户

1. [hadoop@Liu ~]$exit

2. logout

(2)设置suid权限前，该可执行文件的权限：

1. [root@Liu ~]# ll /tmp/cat

2. -rwxr-xr-x 1 root root 48568 Mar 12 00:18 /tmp/cat

(3)设置suid权限后，该可执行文件的权限：

1. [root@Liu ~]# ll /tmp/cat

2. -rwsr-xr-x 1 root root 48568 Mar 12 00:18 /tmp/cat

正如之前我们的结论： 如果该文件之前已有可执行权限，那么设置了suid位权限后，将在该文件属主的可执行权限位上，显示为s

 

sgid：对目录设置

具有sgid的目录，用户在此目录下创建文件时，新建文件的属组不再是用户所属的基本组，而是目录的属组；

(1) 添加测试用的普通用户

1. [root@Liu ~]# useradd openstack

2. [root@Liu ~]# useradd docker

(2)创建测试目录，并查看目录当前的权限

1. [root@Liu ~]# mkdir /tmp/test

2. [root@Liu ~]# ll -d /tmp/test/

3. drwxr-xr-x 2 root root 4096 Mar 12 01:07 /tmp/test/

 

应用场景：假若某公司的A,B两个研发团队，彼此之间需要共享数据，且能修改删除非自己的创建的文件或程序。用户openstack和用户docker分别代表不同的研发团队，/tmp/test则是共享数据存放的目录，而此目录是由root用户创建的，两人默认都没有写的权限，我们如何才能让两个团队的人都可以向该目录存放数据呢？解决方法：先创建一个组，然后把这两个用户都添加到该组，然后再设置sgid权限即可初步实现我们的目标：让两个用户对目录有写权限

(3)新建一个组，名称为cloud

1. [root@Liu ~]# groupadd cloud

(4)添加用户openstack和docker到cloud组

1. [root@Liu ~]# gpasswd  -M openstack,docker cloud

(5)查看是否成功添加用户到组(id username 查看指定用户所属的组)

1. [root@Liu ~]# id openstack

2. uid=501(openstack) gid=501(openstack)groups=501(openstack),503(cloud)

3. [root@Liu ~]# id docker

4. uid=502(docker) gid=502(docker)groups=502(docker),503(cloud)

(6) 为/tmp/test目录的属组添加写(w)权限，并更改属组为cloud

1. [root@Liu ~]# chmod g+w /tmp/test/

2. [root@Liu ~]# chown .cloud /tmp/test/

3. [root@Liu ~]# ll -d /tmp/test/

4. drwxrwxr-x 2 root cloud 4096 Mar 12 01:07 /tmp/test/

扩展：chown修改文件或目录属组2法：chown .cloud /tmp/test/ 或chown :cloud /tmp/test/

理论上，属组cloud已对/tmp/test目录有写权限了，下面我们就对此进行测试...

 

分别以openstack和docker用户的身份登录到系统，在/tmp/test/目录下创建并查看自己的测试文件属主属组

01. [root@Liu ~]# su - openstack

02. [openstack@Liu ~]$cd /tmp/test/

03. [openstack@Liutest]$ touchopen.txt

04. [openstack@Liutest]$ ll open.txt

05. -rw-rw-r-- 1 openstack openstack 0 Mar 12 01:31open.txt

06. [root@Liu ~]# su - docker

07. [docker@Liu ~]$cd /tmp/test/

08. [docker@Liutest]$ touchdoc.txt

09. [docker@Liutest]$ ll doc.txt

10. -rw-rw-r-- 1 docker docker 0 Mar 12 01:32 doc.txt

A、B两个部门的人均可在/tmp/test/写入数据，并且可以修改非自己创建的文件。

 

对/tmp/test目录设置sgid权限，然后再分别以openstack和docker身份创建文件，查看文件属主属组有何变化

01. [root@Liu ~]# ll -d /tmp/test/

02. drwxrwxr-x 2 root cloud 4096 Mar 12 02:19 /tmp/test/

03. [root@Liu ~]# chmod g+s /tmp/test/

04. [root@Liu ~]# ll -d /tmp/test/

05. drwxrwsr-x 2 root cloud 4096 Mar 12 02:19 /tmp/test/

06. [docker@Liutest]$ touchdoc.txt

07. [openstack@Liutest]$ touchope1.txt

08. [openstack@Liutest]$ ll

09. total 0

10. -rw-rw-r-- 1 docker    cloud     0 Mar 12 02:47 doc.txt

11. -rw-rw-r-- 1 openstack cloud     0 Mar 12 02:22 ope1.txt

12. -rw-rw-r-- 1 openstack openstack 0 Mar 12 01:36open.txt

验证结论：设置完sgid权限后，新建文件的属主没有变化，而新建文件的属组都变成了/tmp/test/目录的属组

如果该文件之前已有可执行权限，那么设置了sgid位权限后，将在该文件属组的可执行权限位上，显示为s；

下面这个结论可自己测试下

如果该文件之前没有可执行权限，那么设置了sgid位权限后，将在该文件属组的可执行权限位上，显示为S；

 

思考：接上题，用户docker对/tmp/test目录有写权限，而对该目录下的较早创建的open.txt没有写权限，那用户docker能删除open.txt文件吗？

1. [docker@Liutest]$ rm-rf open.txt

2. [docker@Liutest]$ ll

3. total 0

4. -rw-rw-r-- 1 docker    cloud 0 Mar 12 02:47 doc.txt

5. -rw-rw-r-- 1 openstack cloud 0 Mar 12 02:22 ope1.txt

答案是可以删除。

结论：用户对文件的写权限，不是取决于用户对文件写的权限，而是取决于对写目录的权限

 

在对目录有写权限，但未设置sgid权限的情况下，测试用户是否可以删除属主和属组不是自己的文件

 

以root身份创建测试目录，并设置需要的权限

1. [root@Liu ~]# mkdir /tmp/dirtest

2. [root@Liu ~]# chown .cloud /tmp/dirtest/

3. [root@Liu ~]# chmod g+w /tmp/dirtest/

4. [root@Liu ~]# ll -d /tmp/dirtest/

5. drwxrwxr-x 2 root cloud 4096 Mar 12 02:55 /tmp/dirtest/

分别以openstack和docker身份创建测试文件

1. [docker@Liu dirtest]$touch doctest

2. [openstack@Liutest]$ touchdoc.txt

3. [docker@Liu dirtest]$ ll

4. total 0

5. -rw-rw-r-- 1 docker    docker    0 Mar 12 02:57 doctest

6. -rw-rw-r-- 1 openstack openstack 0 Mar 12 02:57 opentest

查看此时openstack和docker是否能删除属主属组不是自己的文件

1. [openstack@Liu dirtest]$rm -rf doctest

2. [docker@Liu dirtest]$rm -rf opentest

3. [openstack@Liu dirtest]$ ll

4. total 0

答案是可以的，因此用户对文件的写权限，不是取决于用户对文件写的权限，而是取决于对写目录的权限

 

2.粘滞位权限（sticky）

作用：设置粘滞位权限后，即便用户和对目录有写入权限，也不能删除该目录中其他用户的文件

应用场景：对于公共可写目录，用户可创建删除自己的文件，但是不能删除其他用户的文件

表现形式：sticky表示为文件其它用户执行权限位上的t或T：

x: t -: T

若之前在其它用户执行位已有执行权限，则显示为t，否则显示为T

使用，如chmod o+t filename ...

chmod o-t filename ...

数字1表示增加粘滞位权限；数字0表示取消粘滞位权限；

使用,如：chmod 1755 filename ...

 

实例演示：(以上一次操作为前提)

(1)对/tmp/dirtest/设置粘滞位权限

1. [root@Liu ~]# chmod o+t /tmp/dirtest/

2. [root@Liu ~]# ll -d /tmp/dirtest/

3. drwxrwxr-t 2 root cloud 4096 Mar 12 02:58 /tmp/dirtest/

 

(2)测试用户是否能删除非自己创建的文件

1. [docker@Liu dirtest]$touch docker.txt

2. [docker@Liu dirtest]$rm -rf openstack.txt

3. rm: cannot remove `openstack.txt': Operation not permitted

4. [openstack@Liu dirtest]$touch openstack.txt

5. [openstack@Liu dirtest]$rm -rf docker.txt

6. rm: cannot remove `docker.txt': Operation not permitted

答案是否定的。

这样的话，用户可以在此目录中随意创建文件和目录，但是不能删除非自己创建的文件或目录

所以，最终解决方案是：

1. [root@Liu ~]# useradd openstack

2. [root@Liu ~]# useradd docker

3. [root@Liu ~]# groupadd cloud

4. [root@Liu ~]# gpasswd  -M openstack,docker cloud

5. [root@Liu ~]# chmod g+w /tmp/test/

6. [root@Liu ~]# chown .cloud /tmp/test


7.[root@Liu ~]# chmod g+s /tmp/test/

8. [root@Liu ~]# chmod o+t /tmp/test/

这样，openstack和docker用户都可以git目录中创建文件，修改自己以及对方的文件，但是不能删除对方的文件。如果连对方的文件都不允许修改，只要chmod g-s /tmp/test即可。