实际用户ID，有效用户ID，设置用户ID

前段时间一直没搞明白这几个ID之间的关系,今天看到一篇博文,这才拨云见日,才有所了解了.

real user ID:实际用户ID,指的是进程执行者是谁

effective user ID:有效用户ID,指进程执行时对文件的访问权限

saved set-user-ID:保存设置用户ID,作为effective user ID的副本,在执行exec调用时后能重新恢复原来的effectiv user ID.

上面这三个ID是相对于进程而言的.

set-user-ID:设置用户ID,这是相对于文件来说的.设置了set-user-ID位的可执行程序,执行时,进程的effective user ID与saved set-uesr-ID都为程序文件所属用户的ID,些时real user ID与effective user ID就不一定相等了.这类程序称之为SUID程序,这类程序有特殊的用途.典型的例子:passwd程序,ping程序等.

passwd程序是要修改用户密码,此时是要修改/etc/passwd或修改/etc /shadow文件(有必要时),然而一般用户没有修改这两个文件的权限.passwd程序设置了set-user-ID位的,并且该文件的所有都是 root,所以,一般用户执行时,也具有了root的权限.

ping程序也如此,因为ping程序要产生原始套接字(raw),所以需要有root的权限.然而一般用户之所以能用ping程序,就是因为ping程序的所有都是root用户,并且它设置了set-user-ID位.

为一可执行程序设置set-user-ID位:

pds@FSSR:~> su root
口令:
FSSR:/home/pds # chown root suid
FSSR:/home/pds # ll suid
-rwxr-xr-x 1 root users 7702 2008-08-10 11:28 suid
FSSR:/home/pds # chmod u+s suid
FSSR:/home/pds # ll suid
-rwsr-xr-x 1 root users 7702 2008-08-10 11:28 suid
FSSR:/home/pds # exit
exit

 

相对的,没有设置set-user-ID位的可执行程序,称之为非SUID程序,该程序执行时,real user ID与effective user ID相等.

setuid可以修改real user ID,effective user ID和saved set-user-ID这三个值,但是要用权限.

这是函数原型:

int setuid(uid_t uid)

1.如果用户(当前调用的用户)有超级用户权限,则real user ID,effective user ID和saved set-user-ID都将设置为参数uid的值.

2.如果用户没有超级用户权限,仅当参数uid等于real user ID或saved set-user-ID时,effective user ID被设置为参数uid的值,real user ID和saved set-user-ID不变;否则返回错误.

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

一
内核会给每个进程关联两个和进程ID无关的用户ID，一个是真实用户ID，还有一个是有效用户ID或者称为setuid（set user ID）。真实用户ID用于标识由谁为正在运行的进程负责。有效用户ID用于为新创建的文件分配所有权、检查文件访问许可，还用于通过kill系统调用向其 它进程发送信号时的许可检查。内核允许一个进程以调用exec一个setuid程序或者显式执行setuid系统调用的方式改变它的有效用户ID。

所谓setuid程序是指一个设置了许可模式字段中的setuid bit的可执行文件。当一个进程exec一个setuid程序的时候，内核会把进程表以及u区中的有效用户ID设置成该文件所有者的ID。为了区分这两个 字段，我们把进程表中的那个字段称作保存用户ID。可以通过一个例子来演示这两个字段的区别。

setuid系统调用的语法是 setuid(uid) ，其中，uid是新的用户ID，该系统调用的结果取决于有效用户ID的当前值。如果调用进程的有效用户ID是超级用户，内核会把进程表以及u区中的真实和 有效用户ID都设置成uid。如果调用进程的有效用户ID不是超级用户，仅当uid等于真实用户ID或保存用户ID时，内核才会把u区中的有效用户ID设 置成uid。否则，该系统调用将返回错误。一般来说，一个进程会在fork系统调用期间从父进程那儿继承它的真实和有效用户ID，这些数值即使经过 exec系统调用也会保持不变。

存储在u区中的有效用户ID是最近一次setuid系统调用或是exec一个setuid程序的结果；只有它会被用于文件访问许可。进程表中的保存用户ID使得一个进程可以通过执行setuid系统调用把有效用户ID设置成它的值，以此来恢复最初的有效用户ID。

setuid程序的例子：login，mkdir。


二
一个进程的 real user ID 是指运行此进程的用户角色的 ID。
一个进程的 effective user ID 是指此进程目前实际有效的用户 ID（也就是权限的大小），effective user ID 主要用来校验权限时使用，比如打开文件、创建文件、修改文件、kill 别的进程，等等。
如果一个进程是以 root 身份来运行的，那么上面这两个 ID 可以用 setuid/seteuid 随便修改，想怎么改就怎么改，改来改去都可以。
但是如果一个进程是以普通用户身份来运行的，那么上面这两个 ID 一般来说是相同的，并且也不能随便修改。只有一种情况例外：此进程的可执行文件的权限标记中，设置了“设置用户 ID”位！
在命令行中，设置一个可执行文件的“设置用户 ID”位的最简单的方法，就是用

[Copy to clipboard]  [ - ]

CODE:

chmod +s /path/to/file

这个命令。
一旦用了这个命令之后，再执行这个文件，
那么生成的进程的 effective user ID 就变成了这个可执行文件的 owner user ID（属主用户 ID），
而 real user ID 仍然是启动这个程序时所用的用户的 ID。
打个比方来说，如果有这样的一个文件：

QUOTE:

-rw sr- sr-x 1 susesuse susesuse 7902 2006-08-31 13:22 tuid

注意这个文件已经用 chmod +s 命令设置过“设置用户 ID”位了。
然后我用 flw 这个用户来执行它，那么生成的进程它的 real user ID 就是 flw（因为我是用 flw 运行的），但是 effective user ID 就变成了 susesuse（因为这个可执行文件被设置了“设置用户 ID”位，并且它的 owner user ID 是 susesuse）。
这时，这个进程实际上就有两个用户权限了。只不过目前生效的是 susesuse，因此它目前能够且只能够操作 susesuse 用户的文件，如果现在我又想要操作 flw 用户的文件怎么办？
很简单，只需要 seteuid( getuid() ) 就可以了。执行完这句之后，effective user ID 就变成和 real user ID 一样了，都变成 flw 了。

可是如果过了一会儿我又想要变回来怎么办？因为 effective user ID 和 real user ID 此时都变成了 flw 了，所以操作系统必须得有一个地方保存住原来的“设置用户 ID”（也就是可执行文件的 owner user ID），不然等你再想要 seteuid 的时候，操作系统就不知道你有没有那个权利了。（总不能再去访问一次文件系统吧？那样也太没有效率了）

操作系统为了能够在设置了 seteuid 之后，再次设置回来，所以特地将原来的“设置用户 ID”保存下来了，这个保存下来的设置用户 ID 自然就叫做“保存的设置用户 ID”。