[转]实际用户ID,有效用户ID与保存设置用户ID

http://blog.sina.com.cn/s/blog_4ed4269c0100atet.html

前段时间一直没搞明白这几个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位:

:~> 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不变;否则返回错误.

这是自己按自己的理解总结的 ^_^

 

下面看看别人写的:

Unix中常见的几个概念,下面做一个解释.

首先需要明确一点,这几个概念都是和进程相关的.
real user ID表示的是实际上进程的执行者是谁,effective user ID主要用于校验该进程在执行时所获得的文件访问权限,也就是说当进程访问

文件时检查权限时实际上检查的该进程的"effective user ID",saved set-user-ID 仅在effective user ID发生改变时保存.

一般情况下,real user ID就是进程的effective user ID,但是当要运行的可执行程序设置了"set-user-ID"位之后,进程的effective user ID

变成该文件的属主用户id,同时该进程的"saved set-user-ID"变成此时进程的"effective user ID",也就是该可执行程序的属主用户ID,该进程

在执行一些与文件访问权限相关的操作时系统检查的是进程的effective user ID.

为什么需要一个"saved set-user-ID"?因为当进程没有超级用户权限的时候,进程在设置"effective user ID"时需要将需要设置的ID和该进程

的"real user ID"或者"saved set-user-ID"进行比较.

APUE2中进行的解释是:
1)If the process has superuser privileges, the setuid function sets the real user ID, effective user ID, and saved set-user-

ID to uid.

2)If the process does not have superuser privileges, but uid equals either the real user ID or the saved set-user-ID, setuid

sets only the effective user ID to uid. The real user ID and the saved set-user-ID are not changed.

3)If neither of these two conditions is true, errno is set to EPERM, and 1 is returned
也就是说:
1)当用户具有超级用户权限的时候,setuid 函数设置的id对三者都起效.
2)否则,仅当该id为real user ID 或者saved set-user-ID时,该id对effective user ID起效.
3)否则,setuid函数调用失败.

也就是说,这个saved set-user-ID更多的作用是在进程切换自己的effective user ID起作用.

需要特别提醒的是:并没有任何的API可以获取到进程的saved set-user-ID,它仅仅是系统在调用setuid函数时进行比较而起作用的.
APUE2中关于此事的原话如下:
Note that we can obtain only the current value of the real user ID and the effective user ID with the functions getuid and

geteuid from Section 8.2. We can't obtain the current value of the saved set-user-ID.

举一个例子说明问题,假设这样的一种情况,系统中有两个用户A,B,还有一个由B创建的可执行程序proc,该可执行程序的set-
user-id位已经进行了设置.

当A用户执行程序proc时,
程序的real user ID = A的用户ID,effective user ID = B的用户ID,  saved set-user-ID=B的用户ID.

假如在该进程结束了对某些限制只能由用户B访问的文件操作后,程序将effective user ID设置回A,也就是说此时:
程序的real user ID = A的用户ID,effective user ID = A的用户ID,  saved set-user-ID=B的用户ID.

这个改动之所以能成功,原因在于上面列举出的情况2):该ID为进程的real user ID.

最后,假设由于种种原因进程需要再次切换effective user ID为B,可是因为不能通过API获取进程的saved set-user-ID(该值为B的用户ID),所

以只能通过两种途径获得(可能还有别的途径):
a)在设置effective user ID变回A之前保存effective user ID,它的值为B的用户ID.
b)调用函数getpwnam( "B"),在返回的struct passwd *指针中成员pw_uid存放的就是用户B的ID.
这样,这个调用setuid(B的用户ID)就会成功,原因也在于上面说的情况2):该ID与进程的saved set-user-ID相同.

APUE2中关于这几个值的相关解释在section4.4和section8.11中都有涉及.