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

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

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

   默认情况下,在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用户

[hadoop@Liu ~]$ exit
logout

(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.txt

A、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/设置粘滞位权限

[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.txt
rm: cannot remove `openstack.txt‘: Operation not permitted
[openstack@Liu dirtest]$ touch openstack.txt
[openstack@Liu dirtest]$ rm -rf docker.txt
rm: cannot remove `docker.txt‘: Operation not permitted

答案是否定的。

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


本文出自 “Enjoy the process” 博客,谢绝转载!

Linux文件特殊权限之set位权限和粘滞位权限,布布扣,bubuko.com

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

上一篇:Swing获取字符串的宽度和高度


下一篇:Linux下C程序的编译,运行,及调试