首页 > 代码库 > Linux的特殊权限sticky、sgid与数据安全
Linux的特殊权限sticky、sgid与数据安全
Linux 系统中有一个特殊的目录 /tmp 称为临时目录，所有用户都可以在该目录里创建文件，那么就意味着 /tmp目录的权限是 rwxrwxrwx 那么，任何一个用户都可以删除该目录中任意一个文件，这是不允许的。Linux 使用特殊权限sticky: 沾滞位(冒险位)，实现了不能删除属主不是自己(发起删除动作的用户)的文件。但是，由于普通用户的umask值为： 0002. 普通用户在 /tmp创建一个目录，并把自己的临时文件存放在该目录中就不安全了。Sticky 只能保证直属于 /tmp 目录中的文件的安全，并不能保证/tmp目录下的子目录的文件数据的安全。
[admin@Node1 ~]$ umask 0002
使用普通用户 system 在/tmp 目录下创建一个 mytest目录。
[system@Node1 tmp]$ mkdir /tmp/mytest [admin@Node1 tmp]$ ll -d mytest drwxrwxr-x. 3 system system 4096 Jul 4 15:18 mytest
说明：
由于，普通用户的umask 值为：0002，所以创建的目录权限表示为：rwxrwxr-x.
用户能不能在一个目录中创建和删除文件，取决于该用户在该目录中有没有写(r)权限。我们也可以，这样理解：Linux的一个重要哲学思想之一是“一切皆文件”。目录也是文件中的一种。把目录看成一个文件。那么，用户往目录中创建文件，就相当于往该目录文件中添加数据行，删除该目录中的文件就相当于从目录文件中删除数据行。所以，用户要往该目录(目录文件)中创建文件或删除文件，得要有该目录的写权限才可以的。
根据“权限匹配模型”只要发起创建文件(touch,vim或删除文件(rm)进程的用户的属组或附加组是system.那么该用户是可以删除或创建文件的。
下面来看看是不是跟分析的一样呢？
1、把用户：system 的基本组作为用户admin,hadoop 的附加组
这样用户:admin,hadoop就可以在mytest目录中创建文件了。
[root@Node1 tmp]# usermod -a -G systemadmin [root@Node1 tmp]# usermod -a -G systemhadoop [root@Node1 tmp]# id admin uid=500(admin) gid=500(admin)groups=500(admin),501(system) [root@Node1 tmp]# id hadoop uid=4029(hadoop) gid=4029(hadoop)groups=4029(hadoop),501(system)
2、分别以admin 和 hadoop用户身份在/tmp/mytest目录中创建文件
[root@Node1 tmp]# su – hadoop -c ‘touch/tmp/mytest/hadoop.txt‘ [root@Node1 tmp]# su - admin –c ‘touch /tmp/mytest/admin.txt‘
3、查看是否能创建文件呢？
[root@Node1 tmp]# ll mytest total 4 -rw-rw-r--. 1 admin admin 0 Jul 17 16:51 admin.txt -rw-rw-r--. 1 hadoop hadoop 0 Jul 17 16:51 hadoop.txt
分析：
从【ls mytest】显示的结果，知道用户：admin,hadoop创建文件成功了。
4、再以 admin用户的身份删除属主为hadoop的文件和以hadoop用户的身份删除属主为admin的文件
删除前
[root@Node1 ~]# ll /tmp/mytest total 4 -rw-rw-r--. 1 admin admin 0 Jul 17 16:51 admin.txt -rw-rw-r--. 1 hadoop hadoop 0 Jul 17 16:51 hadoop.txt drwx------. 2 root root 4096 Jul 4 15:18 skel
执行删除操作
[root@Node1 ~]# su - admin -c ‘rm -r/tmp/mytest/hadoop.txt‘ [root@Node1 ~]# su - hadoop -c ‘rm -r/tmp/mytest/admin.txt‘
删除后的
[root@Node1 ~]# ll /tmp/mytest total 4 drwx------. 2 root root 4096 Jul 4 15:18 skel
分析：
从上述 【ll /tmp/mytest】结果，得知。发起删除进程的用户 admin和hadoop和被删除的文件所在目录的属组匹配的。它就可以删除
那么，看看管理员在 /tmp/mytest目录中创建的文件，普通用户是否可以删除呢？
以管理员的身份创建文件root.txt
[root@Node1 ~]# touch /tmp/mytest/root.txt [root@Node1 ~]# ll /tmp/mytest total 4 -rw-r--r--. 1 root root 0 Jul 19 15:50 root.txt drwx------. 2 root root 4096 Jul 4 15:18 skel
以普通用户 admin 发起rm 进程去删除管理员创建的文件 root.txt
[root@Node1 ~]# su - admin -c ‘rm -f/tmp/mytest/root.txt‘
查看是否已经把文件删除掉
[root@Node1 ~]# ll /tmp/mytest total 4 drwx------. 2 root root 4096 Jul 4 15:18 skel
分析：
从【ll/tmp/mytest】显示的结果，知道。普通用户已经把属主是管理员(root)的且admin用户没有写(r)权限的root.txt文件删除了。再也再次证明：能否删除目录中的文件是取决于，发起删除进程的用户是否具有被删除文件所在的目录的写权限的。
从上面的实验结果得知：在/tmp/mytest 中创建的文件是没有任何安全性可言的。
普通用户的 umask = 0002。像上面的例子，admin用户的附加组为 system，hadoop用户的附加组也是system。System用户(它是属于system组)在 /tmp创建的目录。该目录中的数据是非常不安全的。
如果，想要，发起删除进程的用户不能删除属主不是自己的文件，那就得给该目录添加特殊控制位 sticky(沾滞位)。添加方法如下：
增加 sticky 之前
[root@Node1 ~]# ll -d /tmp/mytest drwxrwxr-x. 3 system system 4096 Jul 1916:01 /tmp/mytest
使用【chmod】命令添加 sticky 位
[root@Node1 ~]# chmod o+t /tmp/mytest
添加 sticky 之后，目录的其它的权限就最后一位就变成了“t”
[root@Node1 ~]# ll -d /tmp/mytest drwxrwxr-t. 3 system system 4096 Jul 1916:01 /tmp/mytest
测试一下是否能够删除属主不是自己的文件呢？
/tmp/mytest目录中原有的文件
[root@Node1 ~]# ll /tmp/mytest total 4 -rw-rw-r--. 1 hadoop hadoop 0 Jul 19 16:45 hadoop.txt -rw-r--r--. 1 root root 0 Jul 19 16:01 root.txt
以 admin 用户身份发起rm进程删除属主为hadoop和root用户的文件
[root@Node1 ~]# su - admin -c ‘rm -f/tmp/mytest/hadoop.txt‘ rm: cannot remove `/tmp/mytest/hadoop.txt‘:Operation not permitted [root@Node1 ~]# su - admin -c ‘rm -f/tmp/mytest/root.txt‘ rm: cannot remove `/tmp/mytest/root.txt‘:Operation not permitted
从结果:可以看得出不能删除属主不是自己的文件。使用sticky(沾滞位)保证了安全。
还是因为，普通用户的 umask = 0002, 那么用户创建的文件的权限是: rw-rw-r—
用户 admin，hadoop的附加组为 system.所以，system 用户(属于system组)在/tmp
目录或在上面例子中的/tmp/mytest中创建的文件，用户 admin，hadoop都可以修改的。
例子：
[root@Node1 ~]# su - system -c ‘touch/tmp/system.txt‘
以admin用户的身份往属主为system的system.txt写数据
[admin@Node1 ~]$ echo "I admin">> /tmp/system.txt [admin@Node1 ~]$ cat /tmp/system.txt I admin
加了，sticky 位显然不能删除属主不是自己的文件，但是还能修改属主不是自己的文件。这是由于我们创建文件时，文件的权限是根据“umask”的值来定的。所以不想让别的用户修改自己的文件，就把文件的属组和其它的写权限位去掉。
由于用户admin、hadoop的附加组为用户system的直接组systm.所以这两个用户都可以修改属主为system的文件。但是属主为admin的文件，用户hadoop、system是无法修改的。
同样属主为hadoop用户的文件其它两个用户也是无法修改的。用户创建文件的时候，属主和属组就是创建用户的用户名和组名，和所在的目录没有关系。所以只有通过管理员去修改,属主为admin、hadoop的文件的属组为system.这样就可以实现彼此间修改属主不是自己的文件了。那么可不可以通过某种方式，当用户一创建文件，该文件的属组就是文件所在目录的属组呢？这要通过“sgid”特殊权限来实现。
下面来看看是如何实现的：
[root@Node1 ~]# id system uid=501(system) gid=501(system)groups=501(system) [root@Node1 ~]# id admin uid=500(admin) gid=500(admin)groups=500(admin),501(system) [root@Node1 ~]# id hadoop uid=4029(hadoop) gid=4029(hadoop)groups=4029(hadoop),501(system) [root@Node1 ~]# ll /tmp/mytest total 4 -rw-rw-r--. 1 admin admin 0 Jul 19 17:15 admin.txt -rw-rw-r--. 1 hadoop hadoop 0 Jul 19 16:45 hadoop.txt -rw-rw-r--. 1 system system 0 Jul 19 16:52 system.txt
修改属主为hadoop的文件hadoop.txt，修改失败。
[admin@Node1 ~]$ echo "I admin"> /tmp/mytest/hadoop.txt -bash: /tmp/mytest/hadoop.txt: Permissiondenied
给/tmp/mytest添加特殊权限 guid 后，看看是否能够彼此修改属主不是自己的文件？
添加特殊权限sgid 之前
[root@Node1 ~]# ll -d /tmp/mytest drwxrwxr-t. 3 system system 4096 Jul 1917:15 /tmp/mytest
添加特殊权限 sgid
[root@Node1 ~]# chmod g+s /tmp/mytest
添加特殊权限 sgid 后，属组的第三位表示为“s”
[root@Node1 ~]# ll -d /tmp/mytest drwxrwsr-t. 3 system system 4096 Jul 1917:15 /tmp/mytest
看看添加 ugid之后创建文件，文件的属组有什么变化？
分别以不同的用户身份创建文件
[root@Node1 ~]# su - system -c ‘touch/tmp/mytest/system.txt‘ [root@Node1 ~]# su - admin -c ‘touch/tmp/mytest/admin.txt‘ [root@Node1 ~]# su - hadoop -c ‘touch/tmp/mytest/hadoop.txt‘
查看创建文件的结果，三个用户创建的文件的属组已经不再是创建文件用户的组名了，
而是文件所在目录的属组了。这样他们就可以彼此属主不是自己的文件了。
[root@Node1 ~]# ll /tmp/mytest total 4 -rw-rw-r--. 1 admin system 0 Jul 19 17:50 admin.txt -rw-rw-r--. 1 hadoop system 0 Jul 19 17:50 hadoop.txt -rw-rw-r--. 1 system system 0 Jul 19 17:50 system.txt
根据“权限匹配模型”用户admin、hadoop的附加为system.而文件的属组又是system.
且有读写权限。所以它们一定可以彼此修改属主不是自己的文件的，但不能删除属主不是自己的文件由于有 sticky 位。
本文出自 “Linux” 博客，请务必保留此出处http://9528du.blog.51cto.com/8979089/1440295
Linux的特殊权限sticky、sgid与数据安全