chmod命令中的suid和guid

 为什么要使用suid/guid
为什么要使用这种类型的脚本？这里有一个很好的例子。我管理着几个大型的数据库系
统，而对它们进行备份需要有系统管理权限。我写了几个脚本，并设置了它们的g u i d，这样
我指定的一些用户只要执行这些脚本就能够完成相应的工作，而无须以数据库管理员的身份
登录，以免不小心破坏了数据库服务器。通过执行这些脚本，他们可以完成数据库备份及其
他管理任务，但是在这些脚本运行结束之后，他们就又回复到他们作为普通用户的权限。
有相当一些U N I X命令也设置了s u i d和g u i d。如果想找出这些命令，可以进入/ b i n或/ s b i n目
录，执行下面的命令：
$ ls -l | grep '^...s'
上面的命令是用来查找s u i d文件的；
$ ls -l | grep '^...s..s'
上面的命令是用来查找s u i d和g u i d的。
现在我们明白了什么是s u i d，可是如何设置它呢？下面就来介绍这个问题。如果希望设置
s u i d，那么就将相应的权限位之前的那一位设置为4；如果希望设置g u i d，那么就将相应的权限
位之前的那一位设置为2；如果希望两者都置位，那么将相应的权限位之前的那一位设置为4+2。
一旦设置了这一位，一个s将出现在x的位置上。记住：在设置s u i d或g u i d的同时，相应的
执行权限位必须要被设置。例如，如果希望设置g u i d，那么必须要让该用户组具有执行权限。
如果想要对文件l o g i n设置s u i d，它当前所具有的权限为rwx rw- r-- (741)，需要在使用
c h m o d命令时在该权限数字的前面加上一个4，即chmod 4741，这将使该文件的权限变为r w s
rw- r - -。
$ chmod 4741 logit
1.6.2 设置suid/guid的例子
下面给出几个例子：
表1-7 设置s u i d / g u i d

-----------------------------------------------------------------------------




命令            结果                      含义




chmod 4755 rws r-x r- x 文文件被设置了s u i d，文件属主具有读、写和执行的权限，所有其他用户具有读和执行的权限




chmod 6711 rws --s --s 文文件被设置了s u i d和g u i d，文件属主具有读、写和执行的权限，所有其他用户具有执行的权限




chmod 4764 rws rw- r- - 文文件被设置了s u i d，文件属主具有读、写和执行的权限，同组用户具有读和执行的权限，其他用户具有读权限




-------------------------------------------------------------------------------

还可以使用符号方式来设置s u i d / g u i d。如果某个文件具有这样的权限： rwx r-x r- x，那么
可以这样设置其s u i d：
chmod u+s ;
于是该文件的权限将变为： rws r-x r-x
在查找设置了s u i d的文件时，没准会看到具有这样权限的文件：rwS r-x r- x，其中S为大写。
它表示相应的执行权限位并未被设置，这是一种没有什么用处的s u i d设置，可以忽略它的存在。
注意，c h m o d命令不进行必要的完整性检查，可以给某一个没用的文件赋予任何权限，但
chmod 命令并不会对所设置的权限组合做什么检查。因此，不要看到一个文件具有执行权限，
就认为它一定是一个程序或脚本。

 

------------------------------------------------------------

suid/sgid要了解 suid/sgid, 必需先了 解 process 及 permission. 我們需知道: 每個 process 都有其 effective uid/gid , 以決定其在傳 統 unix filesystem 中獲得的實際 permission . 再, process 是由 binary 產生 的, 而 binary 是從 shell / shell script 載入執行. 在正常的情況 下, process 的 effective uid/gid 是從 parent 繼承, 或簡單說是與 shell 的 uid/gid 一 樣. shell 的 uid/gid 則是跟據 /etc/passwd 的第 3 與 第 4 欄位決定. 當我們有了以上的概念之後, 再來 看 suid 對 effective uid/gid 的影響: 若 binary file 帶有 suid/sgid 的時 候, 其 effective id 就不是從 parent 那邊繼承, 而是以 binary file 本身的 user/group 為準. 舉 例而言, 若一個 prog1 的 user/group 都是 root , 但沒設 suid/sgid , 那當一個 uid(500) /gid(500) 的 parent process 執行這個 prog1 的話, 那 effective uid/gid 就 是 500 ... 但若 prog1 設了 suid/sgid 後, 那其 effective uid/gid 就是 root ! 一旦這 個 process effective 是 root 的話, 那它對 file system 的 permission 就如脫繮野馬般任意奔騰而 不受限制了. 因此我才在前面提到木馬程式與病毒的例子... 試想一下: 若病毒的 user/group 被設為 root, 然後被一 般 user 執行時, suid/sgid 的有與無將導致甚麼不同結果? 好了, 由於 suid/sgid 在系統上有其存在的必要性 (舉 /usr/bin/passwd 與 /etc/shadow 為例), 但同時又有極大的殺傷力, 在應用上要異常小心! 因 此, bash shell script 在先天上不支援 suid/sgid 而/bin/zsh是支持suid和sgid的 . perl 亦如 此, 除非額外再安裝 suid-perl .... 
 
 
根据现在的Unix机里，脚本是无法设置suid的，因为真正运行的进程是脚本的解释程序而不是脚本本身
当然，理论上可以让脚本的解释程序获得脚本的suid状态并且动态的改变自己的suid属性，然后在脚本运行完毕后再改回去。不过这样的整个系统 架构的修改可以说不算小，而且也不符合POSIX规范（POSIX规范中没有允许一个正在运行的进程动态修改自身的suid属性） 


由于SUID和SGID是在执行程序（程序的可执行位被设置）时起作用，而可执 行位只对普通文件和目录文件有意义，所以设置其他种类文件的 SUID和SGID位是 没有多大意义的。 首先讲普通文件的SUID和SGID的作用。例子： 如果普通文件myfile是属于foo用户的，是可执行 的，现在没设SUID位，ls命 令显示如下： -rwxr-xr-x 1 foo staff 7734 Apr 05 17:07 myfile 任 何用户都可以执行这个程序。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用户的ui d和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的设备文件，是一个字符设备文件，里面存储了核 心程序要访问的数据，包括用户的口令。所以这个文件不能给一般的用户读写， 权限设 为：cr--r----- 1 root system 2, 1 May 25 1998 kmem 但ps等程序要读这个文件，而ps的权限设置如 下： -r-xr-sr-x 1 bin system 59346 Apr 05 1998 ps 这是一个设置了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位，那么如果任何一个用户对这个目录有写权限的 话，他在这个目录所建立的文件的组都会自动转为这个目录的属主所在的 组，而 文件所有者不变，还是属于建立这个文件的用户.

 

 

suid意味着如果A用户对属于他自己的shell脚本文件设置了这种权限，那么其他用户在执行这个脚本的时候就拥有了A用户的权限。所以，如果 root用户对某一脚本设置了这一权限的话则其他用户执行该脚本的时候则拥有了root用户权限。同理，guid意味着执行相应脚本的用户则拥有了该文件 所属用户组中用户的权限。