进程访问文件时的权限匹配机制：进程的发起者，作为进程的属主；而进程属主所属的基本组作为进程的属组；
进程在确定对文件的访问权限的时候，首先会去查看进程的属主和文件的属主是否一样，若一样，则运用该文件属主的权限，否则则检查进程的属主所属的组(用户可属于多个组)，是否有其中之一与文件的属组匹配，若有，则运用该文件属组的权限，否则，则运用其他权限。
默认情况下，在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)创建测试文件
[root@Liu ~]# cp /bin/cat /tmp/ [root@Liu ~]# cp /etc/fstab /tmp/ [root@Liu ~]# chmod og= /tmp/fstab [root@Liu ~]# ll /tmp/fstab -rw------- 1 root root 921 Mar 12 00:18 /tmp/fstab [root@Liu ~]# ll /tmp/cat -rwxr-xr-x 1 root root 48568 Mar 12 00:18 /tmp/cat(2)添加用户hadoop
[root@Liu ~]# useradd hadoop(3)并切换至用户hadoop
[root@Liu ~]# su - hadoop注：su username和su - username的区别
(4)执行/tmp/cat命令，看是否能查看/tmp/fstab文件中的内容
[hadoop@Liu ~]$ /tmp/cat /tmp/fstab /tmp/cat: /tmp/fstab: Permission denied很明显，权限拒绝，即hadoop无权查看/tmp/fstab文件中的内容
眼见为实，现在，我将为/tmp/cat命令设置suid权限，让您一睹suid的风采...
(5)退出hadoop用户，并以root身份为/tmp/cat设置suid权限
[hadoop@Liu ~]$ exit logout [root@Liu ~]# chmod u+s /tmp/cat(6)此时，我们再切换至hadoop用户，执行/tmp/cat命令，看会出现啥样的效果
[root@Liu ~]# su - hadoop [hadoop@Liu ~]$ /tmp/cat /tmp/fstab # # /etc/fstab # Created by anaconda on Wed Feb 12 16:34:52 2014 # # 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 # /dev/mapper/vg0-root / ext4 defaults 1 1 UUID=5d7ceb50-e9cf-48f2-abe5-6da1b536143e /boot ext4 defaults 1 2 /dev/mapper/vg0-usr /usr ext4 defaults 1 2 /dev/mapper/vg0-var /var ext4 defaults 1 2 /dev/mapper/vg0-swap swap swap defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0简直太神奇了，普通用户hadoop，居然可以查看属主和属组皆为root用户的文件了...
为帮助您加深记忆，那就让我们对比一下，设置suid权限位前后，可执行程序/tmp/cat的权限变化吧...
(1)退出hadoop用户,并切换至root用户
(2)设置suid权限前，该可执行文件的权限：
[root@Liu ~]# ll /tmp/cat -rwxr-xr-x 1 root root 48568 Mar 12 00:18 /tmp/cat(3)设置suid权限后，该可执行文件的权限：
[root@Liu ~]# ll /tmp/cat -rwsr-xr-x 1 root root 48568 Mar 12 00:18 /tmp/cat正如之前我们的结论： 如果该文件之前已有可执行权限，那么设置了suid位权限后，将在该文件属主的可执行权限位上，显示为s
sgid：对目录设置
具有sgid的目录，用户在此目录下创建文件时，新建文件的属组不再是用户所属的基本组，而是目录的属组；
(1) 添加测试用的普通用户
[root@Liu ~]# useradd openstack [root@Liu ~]# useradd docker(2)创建测试目录，并查看目录当前的权限
[root@Liu ~]# mkdir /tmp/test [root@Liu ~]# ll -d /tmp/test/ drwxr-xr-x 2 root root 4096 Mar 12 01:07 /tmp/test/应用场景：假若某公司的A,B两个研发团队，彼此之间需要共享数据，且能修改删除非自己的创建的文件或程序。用户openstack和用户docker分别代表不同的研发团队，/tmp/test则是共享数据存放的目录，而此目录是由root用户创建的，两人默认都没有写的权限，我们如何才能让两个团队的人都可以向该目录存放数据呢？解决方法：先创建一个组，然后把这两个用户都添加到该组，然后再设置sgid权限即可初步实现我们的目标：让两个用户对目录有写权限
(3)新建一个组，名称为cloud
[root@Liu ~]# groupadd cloud(4)添加用户openstack和docker到cloud组
[root@Liu ~]# gpasswd -M openstack,docker cloud(5)查看是否成功添加用户到组(id username 查看指定用户所属的组)
[root@Liu ~]# id openstack uid=501(openstack) gid=501(openstack) groups=501(openstack),503(cloud) [root@Liu ~]# id docker uid=502(docker) gid=502(docker) groups=502(docker),503(cloud)(6) 为/tmp/test目录的属组添加写(w)权限，并更改属组为cloud
[root@Liu ~]# chmod g+w /tmp/test/ [root@Liu ~]# chown .cloud /tmp/test/ [root@Liu ~]# ll -d /tmp/test/ 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/目录下创建并查看自己的测试文件属主属组
[root@Liu ~]# su - openstack [openstack@Liu ~]$ cd /tmp/test/ [openstack@Liu test]$ touch open.txt [openstack@Liu test]$ ll open.txt -rw-rw-r-- 1 openstack openstack 0 Mar 12 01:31 open.txt [root@Liu ~]# su - docker [docker@Liu ~]$ cd /tmp/test/ [docker@Liu test]$ touch doc.txt [docker@Liu test]$ ll doc.txt -rw-rw-r-- 1 docker docker 0 Mar 12 01:32 doc.txtA、B两个部门的人均可在/tmp/test/写入数据，并且可以修改非自己创建的文件。
对/tmp/test目录设置sgid权限，然后再分别以openstack和docker身份创建文件，查看文件属主属组有何变化
[root@Liu ~]# ll -d /tmp/test/ drwxrwxr-x 2 root cloud 4096 Mar 12 02:19 /tmp/test/ [root@Liu ~]# chmod g+s /tmp/test/ [root@Liu ~]# ll -d /tmp/test/ drwxrwsr-x 2 root cloud 4096 Mar 12 02:19 /tmp/test/ [docker@Liu test]$ touch doc.txt [openstack@Liu test]$ touch ope1.txt [openstack@Liu test]$ ll total 0 -rw-rw-r-- 1 docker cloud 0 Mar 12 02:47 doc.txt -rw-rw-r-- 1 openstack cloud 0 Mar 12 02:22 ope1.txt -rw-rw-r-- 1 openstack openstack 0 Mar 12 01:36 open.txt验证结论：设置完sgid权限后，新建文件的属主没有变化，而新建文件的属组都变成了/tmp/test/目录的属组
如果该文件之前已有可执行权限，那么设置了sgid位权限后，将在该文件属组的可执行权限位上，显示为s；
下面这个结论可自己测试下
如果该文件之前没有可执行权限，那么设置了sgid位权限后，将在该文件属组的可执行权限位上，显示为S；
思考：接上题，用户docker对/tmp/test目录有写权限，而对该目录下的较早创建的open.txt没有写权限，那用户docker能删除open.txt文件吗？
[docker@Liu test]$ rm -rf open.txt [docker@Liu test]$ ll total 0 -rw-rw-r-- 1 docker cloud 0 Mar 12 02:47 doc.txt -rw-rw-r-- 1 openstack cloud 0 Mar 12 02:22 ope1.txt答案是可以删除。
结论：用户对文件的写权限，不是取决于用户对文件写的权限，而是取决于对写目录的权限
在对目录有写权限，但未设置sgid权限的情况下，测试用户是否可以删除属主和属组不是自己的文件
以root身份创建测试目录，并设置需要的权限
[root@Liu ~]# mkdir /tmp/dirtest [root@Liu ~]# chown .cloud /tmp/dirtest/ [root@Liu ~]# chmod g+w /tmp/dirtest/ [root@Liu ~]# ll -d /tmp/dirtest/ drwxrwxr-x 2 root cloud 4096 Mar 12 02:55 /tmp/dirtest/分别以openstack和docker身份创建测试文件
[docker@Liu dirtest]$ touch doctest [openstack@Liu test]$ touch doc.txt [docker@Liu dirtest]$ ll total 0 -rw-rw-r-- 1 docker docker 0 Mar 12 02:57 doctest -rw-rw-r-- 1 openstack openstack 0 Mar 12 02:57 opentest查看此时openstack和docker是否能删除属主属组不是自己的文件
[openstack@Liu dirtest]$ rm -rf doctest [docker@Liu dirtest]$ rm -rf opentest [openstack@Liu dirtest]$ ll 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/设置粘滞位权限
(2)测试用户是否能删除非自己创建的文件
答案是否定的。
这样的话，用户可以在此目录中随意创建文件和目录，但是不能删除非自己创建的文件或目录...