Linux 系统中有一个特殊的目录 /tmp 称为临时目录，所有用户都可以在该目录里创建文件，那么就意味着 /tmp目录的权限是 rwxrwxrwx 那么，任何一个用户都可以删除该目录中任意一个文件，这是不允许的。Linux 使用特殊权限sticky: 沾滞位(冒险位)，实现了不能删除属主不是自己(发起删除动作的用户)的文件。但是，由于普通用户的umask值为： 0002. 普通用户在 /tmp创建一个目录，并把自己的临时文件存放在该目录中就不安全了。Sticky 只能保证直属于 /tmp 目录中的文件的安全，并不能保证/tmp目录下的子目录的文件数据的安全。
|
1
2
|
[admin@Node1 ~]$
umask
0002
|
使用普通用户 system 在/tmp 目录下创建一个 mytest目录。
|
1
2
3
|
[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目录中创建文件了。
|
1
2
3
4
5
6
|
[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目录中创建文件
|
1
2
|
[root@Node1 tmp]
# su – hadoop -c 'touch/tmp/mytest/hadoop.txt'
[root@Node1 tmp]
# su - admin –c 'touch /tmp/mytest/admin.txt'
|
3、查看是否能创建文件呢？
|
1
2
3
4
|
[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的文件
删除前
|
1
2
3
4
5
|
[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
|
执行删除操作
|
1
2
|
[root@Node1 ~]
# su - admin -c 'rm -r/tmp/mytest/hadoop.txt'
[root@Node1 ~]
# su - hadoop -c 'rm -r/tmp/mytest/admin.txt'
|
删除后的
|
1
2
3
|
[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
|
1
2
3
4
5
|
[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
|
1
|
[root@Node1 ~]
# su - admin -c 'rm -f/tmp/mytest/root.txt'
|
查看是否已经把文件删除掉
|
1
2
3
|
[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(沾滞位)。添加方法如下：
|
1
|
增加 sticky 之前
|
|
1
2
|
[root@Node1 ~]
# ll -d /tmp/mytest
drwxrwxr-x. 3 system system 4096 Jul 1916:01
/tmp/mytest
|
使用【chmod】命令添加 sticky 位
|
1
|
[root@Node1 ~]
# chmod o+t /tmp/mytest
|
添加 sticky 之后，目录的其它的权限就最后一位就变成了“t”
|
1
2
|
[root@Node1 ~]
# ll -d /tmp/mytest
drwxrwxr-t. 3 system system 4096 Jul 1916:01
/tmp/mytest
|
测试一下是否能够删除属主不是自己的文件呢？
/tmp/mytest目录中原有的文件
|
1
2
3
4
|
[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用户的文件
|
1
2
3
4
|
[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都可以修改的。
例子：
|
1
|
[root@Node1 ~]
# su - system -c 'touch/tmp/system.txt'
|
以admin用户的身份往属主为system的system.txt写数据
|
1
2
3
|
[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”特殊权限来实现。
下面来看看是如何实现的：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
[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，修改失败。
|
1
2
|
[admin@Node1 ~]$
echo
"I admin"
>
/tmp/mytest/hadoop
.txt
-
bash
:
/tmp/mytest/hadoop
.txt: Permissiondenied
|
给/tmp/mytest添加特殊权限 guid 后，看看是否能够彼此修改属主不是自己的文件？
添加特殊权限sgid 之前
|
1
2
|
[root@Node1 ~]
# ll -d /tmp/mytest
drwxrwxr-t. 3 system system 4096 Jul 1917:15
/tmp/mytest
|
添加特殊权限 sgid
|
1
|
[root@Node1 ~]
# chmod g+s /tmp/mytest
|
添加特殊权限 sgid 后，属组的第三位表示为“s”
|
1
2
|
[root@Node1 ~]
# ll -d /tmp/mytest
drwxrwsr-t. 3 system system 4096 Jul 1917:15
/tmp/mytest
|
看看添加 ugid之后创建文件，文件的属组有什么变化？
分别以不同的用户身份创建文件
|
1
2
3
|
[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'
|
查看创建文件的结果，三个用户创建的文件的属组已经不再是创建文件用户的组名了，
而是文件所在目录的属组了。这样他们就可以彼此属主不是自己的文件了。
|
1
2
3
4
5
|
[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 位。
