suid&guid

linux下的命令

有时，没有被授权的用户需要完成某项任务。一个例子是passwd程序，它允许用户改变口令，这就要求改变/etc/passwd文件的口令域。然而系统管理员决不允许普通用户拥有直接改变这个文件的权利，因为这绝对不是一个好主意。

为了解决这个问题，SUID/SGID便应运而生。UNIX允许程序被授权，当程序被执行的时候，拥有超级用户的权限，完成时又回到普通用户的权限。这个主意很好，所以AT&T对它申请了专利。

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

同理，guid意味着执行相应脚本的用户则拥有了该文件所属用户组中用户的权限。g就是group，组。

一、UNIX下关于文件权限的表示方法和解析

    SUID 是 Set User ID, SGID 是 Set Group ID的意思。UNIX下可以用ls -l 命令来看到文件的权限。用ls命令所得到的表示法的格式是类似这样的：-rwxr-xr-x 。下面解析一下格式所表示的意思。这种表示方法一共有十位： 9 8 7 6 5 4 3 2 1 0 - r w x r - x r - x 第9位表示文件类型,可以为p、d、l、s、c、b和-：p表示命名管道文件; d表示目录文件; l表示符号连接文件; -表示普通文件; s表示socket文件; c表示字符设备文件; b表示块设备文件; 第8-6位、5-3位、2-0位分别表示文件所有者的权限，同组用户的权限，其他用户或组的权限，其形式为rwx： r表示可读，可以读出文件的内容； w表示可写，可以修改文件的内容； x表示可执行，可运行这个程序； 没有权限的位置用-表示。 例子： ls -l myfile显示为： -rwxr-x--- 1 foo staff 7734 Apr 05 17:07 myfile 表示文件myfile是普通文件，文件的所有者是foo用户，而foo用户属于staff组，文件只有1个硬连接，长度是7734个字节，最后修改时间4月5日17:07。所有者foo对文件有读写执行权限，staff组的成员对文件有读和执行权限， 其他的用户对这个文件没有权限。
    
	如果一个文件被设置了SUID或SGID位，会分别表现在所有者或同组用户的权限的可执行位上。
	例如： 
	1、-rwsr-xr-x 表示SUID和所有者权限中可执行位被设置
	2、-rwSr--r-- 表示SUID被设置，但所有者权限中可执行位没有被设置
	3、-rwxr-sr-x 表示SGID和同组用户权限中可执行位被设置
	4、-rw-r-Sr-- 表示SGID被设置，但同组用户权限中可执行位没有被社置
	
	其实在UNIX的实现中，文件权限用12个二进制位表示，如果该位置上的值是1，表示有相应的权限：
	11 10 9 8 7 6 5 4 3 2 1 0 S G T r w x r w x r w x 第11位为SUID位，第10位为SGID位，第9位为sticky位，第8-0位对应于上面三组rwx位。 
	11 10 9 8 7 6 5 4 3 2 1 0 上面的-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和SGID的命令如下： chmod u+s filename 设置SUID位； chmod u-s filename 去掉SUID设置； chmod g+s filename 设置SGID位； chmod g-s filename 去掉SGID设置；另外一种方法是chmod命令用八进制表示方法的设置。如果明白了前面的12位 权限表示法也很简单。
	
二、SUID和SGID的详细解析

	由于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用户的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的设备文件，是一个字符设备文件，里面存储了核心程序要访问的数据，包括用户的口令。所以这个文件不能给一般的用户读写， 权限设为：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位，那么如果任何一个用户对这个目录有写权限的话，他在这个目录所建立的文件的组都会自动转为这个目录的属主所在的组，而文件所有者不变，还是属于建立这个文件的用户。