waring_id 的BLOG
用户名：waring_id
文章数：155
评论数：1146
访问量：1664120
注册日期：
阅读量：5863
阅读量：12276
阅读量：299945
阅读量：1019783
51CTO推荐博文
　　不管是Linux新手还是高手，在使用它的时候不可避免都会遇到Linux权限问题。而这些问题也是初学者问得最多的问题，很多的脚本不能执行的原因就是因为没有设定正确的权限所致。这里我们来看看Linux下的根限到底是怎么一回事。
　　当你新建一个文件时，它的最初的权限取决于你的umask值（将在后面说明）。权限可以使用chmod命令或是chmod()系统调用来修改一个文件的权限模式。只有在文件所有者才能修改文件的权限模式。唯一例外的就是超级用户：超级用户可以修改任何文件的权限。下面是chmod命令的格式：
chmod [-Rfh] [agou] [+-=] [rwxXstugol] filelist
要修改哪些用户的特权：
修改所有用户的特权
修改组用户的特权
修改其它用户的特权
修改所有者的权限
执行什么操作：
删除当前的权限
替换当前的权限
增加当前的权限
要修改哪一项权限：
SUID或是SGID
　　其中X是表示由BSD衍生出来的UNIX系统特有的选项，它的意思是：如果文件是一个目录，或有一些其它执行位已设置，那么就将文件设置为只可执行。而l则是由System V衍生出来的UNX系统特有的选项，它的意思是：允许对文件进行强制加锁。
-R选项表示chmod命令会递归执行。如果指定了一个目录filelist，那么目录的权限改变了，目录下所有文件的权限也都改变了。如果该目录包含子目录，那么这一地程会一直向下重复。
-f选项表示强制执行，chmod命令不会报告错误。通常在shell中比较有用。
　　在某些系统中使用-h选项来改变chmod对符号链接的工作方式。如果指定了-h选项，而其中一个参数据为符号链接的话，那么chmod不会改变符号链接所指向的那个文件或目录的权限。
下图说明了命令的使用方法：
计算机八进制的文件权限：
　　chmod允许用户使用一个四位八进制数字来指定文件权限模式。用户可以通过将权限相加的方式来计算这一数值。下表说明了每个文件权限对应的八进制数。
所有者可读
所有者可写
所有者可执行
组成员可读
组成员可写
组成员可执行
其它用户可读
其它用户可写
其它用户可执行
　　因此，一个文件权限如果为“-rwxr-x---”，那么其文件模式为0750，计算过程为：00+50。例如常见的/tmp目录的权限就为1777，表示任何用户都可以在该目录下创建文件，但是用户不能删除其它用户的文件。
　　umask是“用户文件创建模式掩码”的缩写，是一个四位的八进制数值。用来确定一个新创建文件的权限。每个进程都从父进程那里继承了自己的umask。一般该命令会在.bashrc，.profile，.cshrc或是/etc/profile及/etc/bashrc中。
　　最常见的umask值是022，027以及077。022让文件所有者拥有对新建文件的读写权限，但是其它人对此只读。例如：0666（默认的文件建立模式）+0022（umask）=0644。计算umask值最简单的方法是记住：umask值中的2屏蔽了写权限，而7屏蔽了读，写及执行权限。
常用的umask设置：
& 下面的图片是显示新建文件后的权限，大家可以想想看它对应的mask应是多少。
　　具有八进制值1000的位叫粘附位,是unix已经发展得不再需要的事物而又不能摆脱其追随的例子.像unix在其上度过它的孩童期的PDP-11/70这样的小内存系统,需要一些程序持续地驻留在内存或交换设备上这个时候粘附位就十分重要了.在今天由于有了25美圆的内存模块和快速磁盘驱动器,在可执行程序上的粘附位已经过时了,现代的内核已经悄然地忽略了它.　　如果在目录上设置了这个位,那么大多数版本的unix不允许删除或重新命名该目录中的文件,除非你是该目录的属主,该文件的属主或超级用户.在这个目录上拥有写入权限是不够的.这相约定是让像/tmp之类的目录变得多少有些隐私性和安全性的一种尝试.　　Solaris和HP-UX在处理粘附位目录的时候并不那么严格.如果对该目录有写入权限,即使不是属主,也能删除其中的文件.这实际上有许多意义,虽然对实际应用几乎没有什么影响。
SUID和SGID
　　setuid和setgid的位值是0。这些位允许程序访问运它们的用户本来无权访问的文件和进程。当某个目录上设置setgid位时，在这个目录中新创建的文件具有该目录的属组权而不是创建该文件的用户的默认属组。这项约定使得在几个用户之间（只要这些用户都属于同一个组）共享一个目录中的文件变得更简单。在使用这些特性之前，请检查自己的系统，因为并不是所有版本的unix都支持这个特性，当然BSD，REDHAT，HP-UX，SOLARIS都是支持的。对setgid位的这种解释跟它在可执行文件上设置时的含义没有什么关系，但不要混淆了这两种意义。一些系统允许在非可执行的纯文本文件上设置setgid位，以在该文件被打开时请求特殊的锁定。有关它的详细说明可以参考：。在linux下，有关SUID最常用的一个命令就是ping，下面是关于它的图片，好好看看吧。
　　如果对windows比较熟悉的人应对“runas”这个命令不会陌生，我个人觉得SUID及SGID和它有点类似，不过比它要更先进一点。runas允许非特权用户可以用管理员的用户来临时运行特殊的应用程序。不过这个命令在个人计算机上用得比较少，倒是在服务器上用得多一点。使用它在一定的程度可以增加安全性。
　　怎么样，有了一个相对直观的概念了吧，当然这里只是简单的列出这些，更深入的技术还需要过一步的学习和了解。本文出自 “” 博客，转载请与作者联系！
了这篇文章
类别：┆阅读(0)┆评论(0)
11:17:24 11:17:24 01:10:46 01:10:46 10:32:49 10:32:49 09:37:39程序有很多，你做论坛可以选择DZ，博客...
谈到东莞，我想很多人对2013东莞扫黄记...
香港idc机房有香港新世界机房...
天气转凉，但小编为广大网友排忧解难...
经常有人问网通服务器托管和联通服务...
welcome to nginx!字面解释欢迎Nginx...
24小时客服热线：&&景安企业QQ：&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 chmod命令修改文件与文件夹权限的命令附实例
作者：佚名
字体：[ ] 来源：互联网 时间：05-01 20:46:07
在linux中要修改一个文件夹或文件的权限我们需要用到linux chmod命令来做，下面我写了几个简单的实例大家可参考一下
语法：chmod [who] [+ | - | =] [mode] 文件名
命令中各选项的含义为
u 表示&用户（user）&，即文件或目录的所有者。g 表示&同组（group）用户&，即与文件属主有相同组ID的所有用户。o 表示&其他（others）用户&。a 表示&所有（all）用户&。它是系统默认值。操作符号可以是：+ 添加某个权限。- 取消某个权限。= 赋予给定权限并取消其他所有权限（如果有的话）。设置mode所表示的权限可用下述字母的任意组合：r 可读。w 可写。x 可执行。X 只有目标文件对某些用户是可执行的或该目标文件是目录时才追加x 属性。s 在文件执行时把进程的属主或组ID置为该文件的文件属主。方式&u＋s&设置文件的用户ID位，&g＋s&设置组ID位。t 保存程序的文本到交换设备上。u 与文件属主拥有一样的权限。g 与和文件属主同组的用户拥有一样的权限。o 与其他用户拥有一样的权限。
修改文件可读写属性的方法 例如：把index.html 文件修改为可写可读可执行:代码如下:chmod 777 index.html
要修改目录下所有文件属性可写可读可执行:代码如下:chmod 777 *.*
把文件夹名称与后缀名用*来代替就可以了。 比如：修改所有htm文件的属性:
代码如下:chmod 777 *.htm
修改文件夹属性的方法 把目录 /images/xiao 修改为可写可读可执行
代码如下:chmod 777 /images/xiao
修改目录下所有的文件夹属性
代码如下:chmod 777 *
把文件夹名称用*来代替就可以了
要修改文件夹内所有的文件和文件夹及子文件夹属性为可写可读可执行
代码如下:chmod -R 777 /upload
总结linux下目录和文件的权限区别
文件：读文件内容（r）、写数据到文件（w）、作为命令执行文件（x）。目录：读包含在目录中的文件名称（r）、写信息到目录中去（增加和删除索引点的连结）、搜索目录（能用该目录名称作为路径名去访问它所包含的文件和子目录）具体说就是：（1）有只读权限的用户不能用cd进入该目录：还必须有执行权限才能进入。（2）有执行权限的用户只有在知道文件名，并拥有读权利的情况下才可以访问目录下的文件。（3）必须有读和执行权限才可以ls列出目录清单，或使用cd命令进入目录。（4）有目录的写权限，可以创建、删除或修改目录下的任何文件或子目录，即使使该文件或子目录属于其他用户也是如此。查看目录权限 查看文件权限的语句： 　　在终端输入: ls -l xxx.xxx （xxx.xxx是文件名） 　　那么就会出现相类似的信息，主要都是这些： -rw-rw-r-- 　　一共有10位数 　　其中： 最前面那个 - 代表的是类型 　　中间那三个 rw- 代表的是所有者（user） 　　然后那三个 rw- 代表的是组群（group） 　　最后那三个 r-- 代表的是其他人（other） 　　然后我再解释一下后面那9位数： 　　r 表示文件可以被读（read） 　　w 表示文件可以被写（write） 　　x 表示文件可以被执行（如果它是程序的话） 　　- 表示相应的权限还没有被授予 　　现在该说说修改文件权限了 　　在终端输入： 　　chmod o w xxx.xxx 　　表示给其他人授予写xxx.xxx这个文件的权限 　　chmod go-rw xxx.xxx 　　表示删除xxx.xxx中组群和其他人的读和写的权限 　　其中： 　　u 代表所有者（user） 　　g 代表所有者所在的组群（group） 　　o 代表其他人，但不是u和g （other） 　　a 代表全部的人，也就是包括u，g和o 　　r 表示文件可以被读（read） 　　w 表示文件可以被写（write） 　　x 表示文件可以被执行（如果它是程序的话） 　　其中：rwx也可以用数字来代替 　　r ------------4 　　w -----------2 　　x ------------1 　　- ------------0 　　行动： 　　 表示添加权限 　　- 表示删除权限 　　= 表示使之成为唯一的权限 　　当大家都明白了上面的东西之后，那么我们常见的以下的一些权限就很容易都明白了： 　　-rw------- (600) 只有所有者才有读和写的权限 　　-rw-r--r-- (644) 只有所有者才有读和写的权限，组群和其他人只有读的权限 　　-rwx------ (700) 只有所有者才有读，写，执行的权限 　　-rwxr-xr-x (755) 只有所有者才有读，写，执行的权限，组群和其他人只有读和执行的权限 　　-rwx--x--x (711) 只有所有者才有读，写，执行的权限，组群和其他人只有执行的权限 　　-rw-rw-rw- (666) 每个人都有读写的权限 　　-rwxrwxrwx (777) 每个人都有读写和执行的权限
大家感兴趣的内容
12345678910
最近更新的内容Linux特殊文件权限_百度知道
Linux特殊文件权限
可以看到类似这样的权限“drwxrwsrwx”;etc&#47，如果显示的是“-rwxrwxrwT”;usr&#47，惟一不同的是：ll &#47？再如&#47，终于知道为什么执行passwd时;tmp
查看是否加了SGID。Linux特殊文件权限有三个玩意;;tmp目录默认权限是777：“drwsrwxrwx”，使目录下的文件，仅属于group或者other，需要加上777的权限。例如&#47，用ls -l，用ls -l;tmp或
chmod 2777 &#47：sticky bit，加了SUID的文件权限有这类似这两种，表示运行这个程序时。
看看&#47，就是drwxrwxrwt吧
SGID(The Set GroupID )
加上SGID的文件。
sticky bit
sticky bit只对目录有效;tmp目录的权限;tmp
同样的，是&quot，s就代表已经加上了SGID，只有文件拥有者才能删除（如果他不属于owner，t就代表已经加上了sticky bit。
但仔细一想：
chmod o+s /etc&#47，但没有生效（因为本来group就没有执行的权限），但没有生效（因为本来other就没有写的权限），可以修改&#47。
SUID(The Set UserID)
SUID与SGID是一样的，说明已经加上了SGID。
加sticky bit的方法，是临时以这个文件的拥有组的身份运行的，也不能删除文件），没有考滤特殊情况、其它用户的rwx权限是彼此独立的，按照常规理解，Linux文件的权限有rwx、SGID，如果显示“drwxrwSrwx”，而且生效;bin&#47，而且生效了，因为每个用户都可能修改密码。
加SGID的方法，而且有些文件也是允许所有用户访问修改的、SUID，需要引入Linux特殊文件权限的概念，在这个目录下创建的目录继承本目录的SGID，经常会听到如果某个web文件需要被修改的话，运行时是以这个文件的拥有者身份来运行，表示在这个目录下创建的文件属于目录所有的组，以下一一道来、所有组；加上SGID的文件夹，可以看到有类似这样的权限;-rwsr-x-rx&quot：“-rwxrwxrwt”，默认情况下它的权限是640，也就是会修改这个文件;tmp
查看是否加了tmp或
chmod 4777 &#47：
chmod o+t &#47，这样的权限未免有些想得比较天真，就算他有w权限。
看看passwd命令的权限，这是不可理解的;tmp或者
chmod 1777 /passwd，那么是不是任何一个用户都可以将这些删除呢、“drwSrwxrwx”，说明也已经加上了sticky bit，所有者，使用过Linux的同学都知道一般来说，而不是创建人所在的组，那么只有shadow的owner(root)才能修改它。为此。
为了把这些情况解释清楚;shadow保存的是用户密码文件，这就是让所有用户可写;shadow文件了吧。
加SUID的方法：
chmod g+s &#47
我有更好的答案
啊哈，除此之外，可以看看粘置位噢。
啊哈，除此之外，可以看看粘置位噢。
你想表达个什么意思?
其他类似问题
4人觉得有用
为您推荐：
linux的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁