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.txt09.[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.txt07.[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−rfopen.txt2.[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] touchdoctest2.[openstack@Liutest] touchdoc.txt
3.[docker@Liu dirtest] ll4.total05.−rw−rw−r–1dockerdocker0Mar1202:57doctest6.−rw−rw−r–1openstackopenstack0Mar1202:57opentest查看此时openstack和docker是否能删除属主属组不是自己的文件1.[openstack@Liudirtest] rm -rf doctest
2.[docker@Liu dirtest] rm−rfopentest3.[openstack@Liudirtest] 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] touchdocker.txt2.[docker@Liudirtest] 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 removedocker.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即可。

本文转载自http://blog.csdn.net/hshl1214/article/details/45563235