粘滞位（Sticky&bit），或粘，是Unix文件系统权限的一个旗标。最常见的用法在目录上设置粘滞位，如此以来，只有目录内文件的所有者或者root才可以删除或移动该文件。如果不为目录设置粘滞位，任何具有该目录写和执行权限的用户都可以删除和移动其中的文件。实际应用中，粘滞位一般用于/tmp目录，以防止普通用户删除或移动其他用户的文件。
&|&相关影像
互动百科的词条（含所附图片）系由网友上传，如果涉嫌侵权，请与客服联系，我们将按照法律之相关规定及时进行处理。未经许可，禁止商业网站等复制、抓取本站内容；合理使用者，请注明来源于。
登录后使用互动百科的服务，将会得到个性化的提示和帮助，还有机会和专业认证智愿者沟通。
此词条还可添加&
编辑次数：1次
参与编辑人数：1位
最近更新时间： 21:10:27
认领可获得以下专属权利：
贡献光荣榜Linux粘滞位使用粘滞位（Stickybit），又称粘着位，是Unix文件系统权限的一个旗标。最常见的用法在目录上设置粘滞位，也只能针对目录设置，对于目录内文件有效。则设置了粘滞位后，只有目录内文件的所有者或者root才可以删除或移动该文件。如果不为目录设置粘滞位，任何具有该目录写和执行权限的用户都可以删除和移动其中的文件。实际应用中，粘滞位一般于/tmp目录，以防止普通用户删除或移动其他用户的文件。在Linux系统中比较典型的例子就是“/tmp”、 “/var/tmp”目录。这两个目录作为Linux系统的临时文件夹，权限为“rwxrwxrwx”，即允许任意用户、任意程序在该目录中进行创建、删除、移动文件或目录等操作。　　粘滞位权限便是针对此种情况设置，当目录被设置了粘滞位权限以后，即便用户对该文录有写入权限，也不能删除该目录中其他用户的文件数据，只有该文件的所有者和root用户才有权将其删除。设置了粘滞位之后，正好可以保持一种动态的平衡：允许各用户在目录中任意写入、删除数据，但是禁止随意删除其他用户的数据。　　需要注意的是， 粘滞位权限只能针对目录设置，对于文件无效。 　　设置了粘滞位权限的目录，使用ls命令查看其属性时，其他用户权限处的“x”将变为“t”。 　　例如，查看/tmp、 /var/tmp目录的权限，确认存在“t”标记。 　　 　　粘滞位权限都是针对其他?户（ other）设置，使用chmod命令设置目录权限时，“o+t”、 “o-t”权限模式可分别用于添加、移除粘滞位权限。 　　例如，为/file目录设置粘滞位权限。 　　 　　 Linux 文件权限的表示方法 文件权限用 12 个二进制位表示，如果该位的值是 1，表示有相应的权限：
11 10 9 8 7 6 5 4 3 2 1 0
r w x r w x r w x
第 11 位为 SUID 位，第 10 位为 SGID 位，第 9 位为 sticky 位，第 8-0 位对应于上面的三组 rwx 位。
-rwsr-xr-x的值为： 1 0 0 1 1 1 1 0 1 1 0 1
-rw-r-Sr–的值为： 0 1 0 1 1 0 1 0 0 1 0 0给文件加 SUID 和 SUID 的命令如下：
chmod u+s filename 设置SUID位
chmod u-s filename 去掉SUID设置
chmod g+s filename 设置SGID位
chmod g-s filename 去掉SGID设置
另外一种方法是 chmod 命令用八进制表示方法的设置。SUID 和 SGID 的详细解析由于 SUID 和 SGID 是在执行程序（程序的可执行位被设置）时起作用，而可执行位只对普通文件和目录文件有意义，所以设置其他种类文件的 SUID 和 SGID 位是没有多大意义的。
首先讲普通文件的 SUID 和 SGID 的作用。
如果普通文件 file 是属于 foo 用户的，是可执行的，现在没设 SUID 位，ls 命令显示如下：
-rwxr-xr-x 1 foo staff 7734
Aug 26 17:07 file
任何用户都可以执行这个程序。UNIX 的内核是根据什么来确定一个进程对资源的访问权限的呢？是这个进程的运行用户的（有效）ID，包括 user id 和 group id。用户可以用 id 命令来查到自己的或其他用户的 user id 和 group id。
除了一般的 user id 和 group id 外，还有两个称之为 effective 的 id，就是有效 id，上面的四个 id 表示为：uid，gid，euid，egid。内核主要是根据 euid 和 egid 来确定进程对资源的访问权限。一个进程如果没有 SUID 或 SGID 位，则 euid=uid egid=gid，分别是运行这个程序的用户的 uid 和 gid。例如 kevin 用户的 uid 和 gid 分别为 204 和 202，foo 用户的 uid 和 gid 分别为 200 和 201，kevin 运行 myfile 程序形成的进程的 euid=uid=204，egid=gid=202，内核根据这些值来判断进程对资源访问的限制，其实就是 kevin 用户对资源访问的权限，和 foo 没关系。
如果一个程序设置了 SUID，则 euid 和 egid 变成被运行的程序的所有者的 uid 和 gid，例如 kevin 用户运行 myfile，euid=200，egid=201，uid=204，gid=202，则这个进程具有它的属主 foo 的资源访问权限。
SUID 的作用就是这样：让本来没有相应权限的用户运行这个程序时，可以访问他没有权限访问的资源。passwd 就是一个很鲜明的例子。
SUID 的优先级比 SGID 高，当一个可执行程序设置了 SUID，则 SGID 会自动变成相应的 egid。
下面讨论一个例子：
UNIX 系统有一个 /dev/kmem 的设备文件，是一个字符设备文件，里面存储了核心程序要访问的数据，包括用户的口令。所以这个文件不能给一般的用户读写。
这是一个设置了 SGID 的程序，而 ps 的用户是 bin，不是 root，所以不能设置 SUID 来访问 kmem，但大家注意了，bin 和 root 都属于 system 组，而且 ps 设置了 SGID，一般用户执行 ps，就会获得 system 组用户的权限，而文件 kmem 的同组用户的权限是可读，所以一般用户执行 ps 就没问题了。但有些人说，为什么不把 ps 程序设置为 root 用户的程序，然后设置 SUID 位，不也行吗？这的确可以解决问题，但实际中为什么不这样做呢？因为 SGID 的风险比 SUID 小得多，所以出于系统安全的考虑，应该尽量用 SGID 代替 SUID 的程序，如果可能的话。下面来说明一下 SGID 对目录的影响。SUID 对目录没有影响。如果一个目录设置了 SGID 位，那么如果任何一个用户对这个目录有写权限的话，他在这个目录所建立的文件的组都会自动转为这个目录的属主所在的组，而文件所有者不变，还是属于建立这个文件的用户。
最新教程周点击榜
微信扫一扫时间： 23:43:46
&&&& 阅读：47
&&&& 评论：
&&&& 收藏：0
标签：&&&&&&&&&&&&&&&粘滞位，或粘着位，是Unix文件系统权限的一个旗标。最常见的用法在目录上设置粘滞位，如此一来，只有目录文件的所有者或者root才可以删除或移动该文件。如果不为目录设置粘滞位，任何具有该目录写和执行权限的用户都可以删除和移动其中的文件。实际应用中，粘滞位一般用于/tmp目录，防止普通用户删除或移动其他用户的文件。在Linux系统中比较典型的例子就是"/tmp"，"/var/tmp"目录。这两个目录作为Linux系统的临时文件夹，权限为即允许任意用户，任意程序在该目录中进行创建，删除，移动文件或子目录等操作。但是如果任意用户都能删除系统服务运行中使用的临时文件，后果不言而喻。而粘滞位权限就是针对这种情况设置当目录设置了粘滞位权限后，几遍用户对该目录有写入权限，也不能删除目录中其他用户的文件数据，而只有文件持有者root才有去哪删除。需要注意的是，粘滞位权限只能针对目录设置，对于文件无效粘滞位权限都是针对其他用户设置；使用chmod o+t filename填加粘滞位权限使用chmod o-t filename移除粘滞位权限本文出自 “” 博客，谢绝转载！标签：&&&&&&&&&&&&&&&
&&国之画&&&& &&
版权所有 京ICP备号-2
迷上了代码！Linux文件特殊权限之set位权限和粘滞位权限
我的图书馆
Linux文件特殊权限之set位权限和粘滞位权限
进程访问文件时的权限匹配机制：进程的发起者，作为进程的属主；而进程属主所属的基本组作为进程的属组；
进程在确定对文件的访问权限的时候，首先会去查看进程的属主和文件的属主是否一样，若一样，则运用该文件属主的权限，否则则检查进程的属主所属的组(用户可属于多个组)，是否有其中之一与文件的属组匹配，若有，则运用该文件属组的权限，否则，则运用其他权限。
默认情况下，在系统中，我们创建的目录的权限是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)创建测试文件
1.[root@Liu ~]# cp /bin/cat /tmp/2.[root@Liu ~]# cp /etc/fstab /tmp/3.[root@Liu ~]# chmod og= /tmp/fstab4.[root@Liu ~]# ll /tmp/fstab5.-rw------- 1 root root 921 Mar 12 00:18 /tmp/fstab6.[root@Liu ~]# ll /tmp/cat7.-rwxr-xr-x 1 root root 48568 Mar 12 00:18 /tmp/cat
(2)添加用户hadoop
1.[root@Liu ~]# useradd hadoop
(3)并切换至用户hadoop
1.[root@Liu ~]# su - hadoop
注：su username和su - username的区别
(4)执行/tmp/cat命令，看是否能查看/tmp/fstab文件中的内容
1.[hadoop@Liu ~]$ /tmp/cat /tmp/fstab2./tmp/cat: /tmp/fstab: Permission denied
很明显，权限拒绝，即hadoop无权查看/tmp/fstab文件中的内容
眼见为实，现在，我将为/tmp/cat命令设置suid权限，让您一睹suid的风采...
(5)退出hadoop用户，并以root身份为/tmp/cat设置suid权限
1.[hadoop@Liu ~]$ exit2.logout3.[root@Liu ~]# chmod u+s /tmp/cat
(6)此时，我们再切换至hadoop用户，执行/tmp/cat命令，看会出现啥样的效果
01.[root@Liu ~]# su - hadoop02.[hadoop@Liu ~]$ /tmp/cat /tmp/fstab03.#04.# /etc/fstab05.# Created by anaconda on Wed Feb 12 16:34:52 201406.#07.# Accessible filesystems, by reference, are maintained under '/dev/disk'08.# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info09.#10./dev/mapper/vg0-root&&& /&&&&&&&&&&&&&&&&&&&&&& ext4&&& defaults&&&&&&& 1 111.UUID=5d7ceb50-e9cf-48f2-abe5-6da1b536143e /boot&&&&&&&&&&&&&&&&&& ext4&&& defaults&&&&&&& 1 212./dev/mapper/vg0-usr&&&& /usr&&&&&&&&&&&&&&&&&&& ext4&&& defaults&&&&&&& 1 213./dev/mapper/vg0-var&&&& /var&&&&&&&&&&&&&&&&&&& ext4&&& defaults&&&&&&& 1 214./dev/mapper/vg0-swap&&& swap&&&&&&&&&&&&&&&&&&& swap&&& defaults&&&&&&& 0 015.tmpfs&&&&&&&&&&&&&&&&&& /dev/shm&&&&&&&&&&&&&&& tmpfs&& defaults&&&&&&& 0 016.devpts&&&&&&&&&&&&&&&&& /dev/pts&&&&&&&&&&&&&&& devpts& gid=5,mode=620& 0 017.sysfs&&&&&&&&&&&&&&&&&& /sys&&&&&&&&&&&&&&&&&&& sysfs&& defaults&&&&&&& 0 018.proc&&&&&&&&&&&&&&&&&&& /proc&&&&&&&&&&&&&&&&&& proc&&& defaults&&&&&&& 0 0
简直太神奇了，普通用户hadoop，居然可以查看属主和属组皆为root用户的文件了...
为帮助您加深记忆，那就让我们对比一下，设置suid权限位前后，可执行程序/tmp/cat的权限变化吧...
(1)退出hadoop用户,并切换至root用户
1.[hadoop@Liu ~]$ exit2.logout
(2)设置suid权限前，该可执行文件的权限：
1.[root@Liu ~]# ll /tmp/cat2.-rwxr-xr-x 1 root root 48568 Mar 12 00:18 /tmp/cat
(3)设置suid权限后，该可执行文件的权限：
1.[root@Liu ~]# ll /tmp/cat2.-rwsr-xr-x 1 root root 48568 Mar 12 00:18 /tmp/cat
正如之前我们的结论： 如果该文件之前已有可执行权限，那么设置了suid位权限后，将在该文件属主的可执行权限位上，显示为s
sgid：对目录设置
具有sgid的目录，用户在此目录下创建文件时，新建文件的属组不再是用户所属的基本组，而是目录的属组；
(1) 添加测试用的普通用户
1.[root@Liu ~]# useradd openstack2.[root@Liu ~]# useradd docker
(2)创建测试目录，并查看目录当前的权限
1.[root@Liu ~]# mkdir /tmp/test2.[root@Liu ~]# ll -d /tmp/test/3.drwxr-xr-x 2 root root 4096 Mar 12 01:07 /tmp/test/
应用场景：假若某公司的A,B两个研发团队，彼此之间需要共享数据，且能修改删除非自己的创建的文件或程序。用户openstack和用户docker分别代表不同的研发团队，/tmp/test则是共享数据存放的目录，而此目录是由root用户创建的，两人默认都没有写的权限，我们如何才能让两个团队的人都可以向该目录存放数据呢？解决方法：先创建一个组，然后把这两个用户都添加到该组，然后再设置sgid权限即可初步实现我们的目标：让两个用户对目录有写权限
(3)新建一个组，名称为cloud
1.[root@Liu ~]# groupadd cloud
(4)添加用户openstack和docker到cloud组
1.[root@Liu ~]# gpasswd& -M openstack,docker cloud
(5)查看是否成功添加用户到组(id username 查看指定用户所属的组)
1.[root@Liu ~]# id openstack2.uid=501(openstack) gid=501(openstack) groups=501(openstack),503(cloud)3.[root@Liu ~]# id docker4.uid=502(docker) gid=502(docker) groups=502(docker),503(cloud)
(6) 为/tmp/test目录的属组添加写(w)权限，并更改属组为cloud
1.[root@Liu ~]# chmod g+w /tmp/test/2.[root@Liu ~]# chown .cloud /tmp/test/3.[root@Liu ~]# ll -d /tmp/test/4.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/目录下创建并查看自己的测试文件属主属组
01.[root@Liu ~]# su - openstack02.[openstack@Liu ~]$ cd /tmp/test/03.[openstack@Liu test]$ touch open.txt04.[openstack@Liu test]$ ll open.txt05.-rw-rw-r-- 1 openstack openstack 0 Mar 12 01:31 open.txt06.[root@Liu ~]# su - docker07.[docker@Liu ~]$ cd /tmp/test/08.[docker@Liu test]$ touch doc.txt09.[docker@Liu test]$ ll doc.txt10.-rw-rw-r-- 1 docker docker 0 Mar 12 01:32 doc.txt
A、B两个部门的人均可在/tmp/test/写入数据，并且可以修改非自己创建的文件。
对/tmp/test目录设置sgid权限，然后再分别以openstack和docker身份创建文件，查看文件属主属组有何变化
01.[root@Liu ~]# ll -d /tmp/test/02.drwxrwxr-x 2 root cloud 4096 Mar 12 02:19 /tmp/test/03.[root@Liu ~]# chmod g+s /tmp/test/04.[root@Liu ~]# ll -d /tmp/test/05.drwxrwsr-x 2 root cloud 4096 Mar 12 02:19 /tmp/test/06.[docker@Liu test]$ touch doc.txt07.[openstack@Liu test]$ touch ope1.txt08.[openstack@Liu test]$ ll09.total 010.-rw-rw-r-- 1 docker&&& cloud&&&& 0 Mar 12 02:47 doc.txt11.-rw-rw-r-- 1 openstack cloud&&&& 0 Mar 12 02:22 ope1.txt12.-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文件吗？
1.[docker@Liu test]$ rm -rf open.txt2.[docker@Liu test]$ ll3.total 04.-rw-rw-r-- 1 docker&&& cloud 0 Mar 12 02:47 doc.txt5.-rw-rw-r-- 1 openstack cloud 0 Mar 12 02:22 ope1.txt
答案是可以删除。
结论：用户对文件的写权限，不是取决于用户对文件写的权限，而是取决于对写目录的权限
在对目录有写权限，但未设置sgid权限的情况下，测试用户是否可以删除属主和属组不是自己的文件
以root身份创建测试目录，并设置需要的权限
1.[root@Liu ~]# mkdir /tmp/dirtest2.[root@Liu ~]# chown .cloud /tmp/dirtest/3.[root@Liu ~]# chmod g+w /tmp/dirtest/4.[root@Liu ~]# ll -d /tmp/dirtest/5.drwxrwxr-x 2 root cloud 4096 Mar 12 02:55 /tmp/dirtest/
分别以openstack和docker身份创建测试文件
1.[docker@Liu dirtest]$ touch doctest2.[openstack@Liu test]$ touch doc.txt3.[docker@Liu dirtest]$ ll4.total 05.-rw-rw-r-- 1 docker&&& docker&&& 0 Mar 12 02:57 doctest6.-rw-rw-r-- 1 openstack openstack 0 Mar 12 02:57 opentest
查看此时openstack和docker是否能删除属主属组不是自己的文件
1.[openstack@Liu dirtest]$ rm -rf doctest2.[docker@Liu dirtest]$ rm -rf opentest3.[openstack@Liu dirtest]$ ll4.total 0
答案是可以的，因此用户对文件的写权限，不是取决于用户对文件写的权限，而是取决于对写目录的权限
2.粘滞位权限（sticky）
作用：设置粘滞位权限后，即便用户和对目录有写入权限，也不能删除该目录中其他用户的文件
应用场景：对于公共可写目录，用户可创建删除自己的文件，但是不能删除其他用户的文件
表现形式：sticky表示为文件其它用户执行权限位上的t或T：
若之前在其它用户执行位已有执行权限，则显示为t，否则显示为T
使用，如chmod o+t filename ...
chmod o-t filename ...
数字1表示增加粘滞位权限；数字0表示取消粘滞位权限；
使用,如：chmod 1755 filename ...
实例演示：(以上一次操作为前提)
(1)对/tmp/dirtest/设置粘滞位权限
1.[root@Liu ~]# chmod o+t /tmp/dirtest/2.[root@Liu ~]# ll -d /tmp/dirtest/3.drwxrwxr-t 2 root cloud 4096 Mar 12 02:58 /tmp/dirtest/
(2)测试用户是否能删除非自己创建的文件
1.[docker@Liu dirtest]$ touch docker.txt2.[docker@Liu dirtest]$ rm -rf openstack.txt3.rm: cannot remove `openstack.txt': Operation not permitted4.[openstack@Liu dirtest]$ touch openstack.txt5.[openstack@Liu dirtest]$ rm -rf docker.txt6.rm: cannot remove `docker.txt': Operation not permitted
答案是否定的。
这样的话，用户可以在此目录中随意创建文件和目录，但是不能删除非自己创建的文件或目录...
TA的最新馆藏Linux（33）
/blog/921961
&&&& 今天维护系统时发现一个非常诡异的问题：AAA用户和BBB用户同属AAA组，但用AAA用户创建的文件，权限设置为777后，还是不能用BBB用户删除。诡异！
&&&& 几经周转，发现AAA用户创建文件位置的上层目录的权限是drwxrwxrwt,做开发这么多年了，还没见过所谓&t&的权限，于是找了一位公司的 linux大师帮忙，大师噼里啪啦的做了一堆试验后，然后在google上搜索&rwt linux&,终于发现了问题，发现这种用法的名字是“文件的粘滞位(sticky)位“。它的作用是：普通文件的sticky位会被linux内核忽 略，但
目录的sticky位表示这个目录里的文件只能被owner和root删除，没错这就是问题本质，也和我的现象相吻合。于是用root用 户，对这个文件夹chmod -t 后，用BBB用户就可以删除刚才AAA用户创建的文件了。一切正常了。哇。。。。世界太平了！真是长见识了。所以将这个知识点整理如下：
Python代码 &
文件的粘滞位(sticky)位是作什么用的？&&普通文件的sticky位会被linux内核忽略，&&目录的sticky位表示这个目录里的文件只能被owner和root删除&&&&粘着位（Sticky&bit）&&如果用户对目录有写权限，则可以删除其中的文件和子目录，即使该用户不是这些文件的所有者，而且也没有读或写许可。粘着位出现执行许可的位置上，用t表示，设置了该位后，其它用户就不可以删除不属于他的文件和目录。但是该目录下的目录不继承该权限，要再设置才可使用。&&&&&&&#&chmod&1770&xxx&&&&举一个linux下的常见目录来做例子，也就是&/tmp&目录来说一下粘连位的作用。&&#ls&-dl&/tmp&&drwxrwxrwt&4&root&&&&root&&.........&&注意other位置的t，这便是粘连位。&&我们都知道，/tmp常被我们用来存放临时文件，是所有用户。但是我们不希望别的用户随随便便的就删除了自己的文件，于是便有了粘连位，它的作用便是让用户只能删除属于自己的文件。&&&&那么原来的执行标志x到哪里去了呢?&系统是这样规定的,&假如本来在该位上有x,&则这些特别标志&(suid,&sgid,&sticky)&显示为小写字母&(s,&s,&t).&否则,&显示为大写字母&(S,&S,&T)&。&&&&&&3)粘着位(sticky)&&&&eg:&&&&chmod&777&abc&&&&chmod&+t&abc&&&&等价于&&&&chmod&1777&abc&&&&在以前旧的系统当中,如果一个程序文件一旦设置了粘着位,&&那么当该程序中止的时候他的所有指令段将被保存到系统的交换分区当中,&&再次运行时可以更快的调入系统.&&&&不过现在的操作系统已经不再使用这种功能了.&&但这并不表示这一功能已经完全被废弃.&&当一个目录设置为粘着位时，它将发挥特殊的作用,&&&&即当一个目录被设置为&粘着位&(用chmod&a+t),则该目录下的文件只能由&&一、超级管理员删除&&二、该目录的所有者删除&&三、该文件的所有者删除&&也就是说,即便该目录是任何人都可以写,但也只有文件的属主才可以删除文件。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：41173次
排名：千里之外
原创：37篇
转载：108篇
(24)(2)(11)(19)(7)(11)(18)(1)(3)(17)(17)(16)