|
进程访问文件时的权限匹配机制：进程的发起者，作为进程的属主；而进程属主所属的基本组作为进程的属组；进程在确定对文件的访问权限的时候，首先会去查看进程的属主和文件的属主是否一样，若一样，则运用该文件属主的权限，否则则检查进程的属主所属的组(用户可属于多个组)，是否有其中之一与文件的属组匹配，若有，则运用该文件属组的权限，否则，则运用其他权限。默认情况下，在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；否则显示为Ssgid位权限的表现形式：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 ~]$ exitlogout[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 1UUID=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 0tmpfs /dev/shm tmpfs defaults 0 0devpts /dev/pts devpts gid=5,mode=620 0 0sysfs /sys sysfs defaults 0 0proc /proc proc defaults 0 0简直太神奇了，普通用户hadoop，居然可以查看属主和属组皆为root用户的文件了...为帮助您加深记忆，那就让我们对比一下，设置suid权限位前后，可执行程序/tmp/cat的权限变化吧...(1)退出hadoop用户,并切换至root用户[hadoop@Liu ~]$ exitlogout(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位权限后，将在该文件属主的可执行权限位上，显示为ssgid：对目录设置具有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 openstackuid=501(openstack) gid=501(openstack) groups=501(openstack),503(cloud)[root@Liu ~]# id dockeruid=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]$ lltotal 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]$ lltotal 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]$ lltotal 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]$ lltotal 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/设置粘滞位权限[root@Liu ~]# chmod o+t /tmp/dirtest/[root@Liu ~]# ll -d /tmp/dirtest/drwxrwxr-t 2 root cloud 4096 Mar 12 02:58 /tmp/dirtest/(2)测试用户是否能删除非自己创建的文件[docker@Liu dirtest]$ touch docker.txt[docker@Liu dirtest]$ rm -rf openstack.txtrm: cannot remove `openstack.txt': Operation not permitted[openstack@Liu dirtest]$ touch openstack.txt[openstack@Liu dirtest]$ rm -rf docker.txtrm: cannot remove `docker.txt': Operation not permitted答案是否定的。这样的话，用户可以在此目录中随意创建文件和目录，但是不能删除非自己创建的文件或目录...
(以上内容不代表本站观点。) --------------------------------- |
本網站是"非商業"(non-commercial)。
