linux processes identifiers

Linux, like all Unix uses user and group identifiers to check for access rights to files and images in the system. All of the files in a Linux system have ownerships and permissions, these permissions describe what access the system's users have to that file or directory. Basic permissions are read, write and execute and are assigned to three classes of user; the owner of the file, processes belonging to a particular group and all of the processes in the system. Each class of user can have different permissions, for example a file could have permissions which allow its owner to read and write it, the file's group to read it and for all other processes in the system to have no access at all. REVIEW NOTE: Expand and give the bit assignments (777).

Groups are Linux's way of assigning privileges to files and directories to a group of users rather than to a single user or to all processes in the system. You might, for example, create group for all of the users in a software project and arrange it so that only they could read and write the source code for the project. A process can belong to several groups (a maximum of 32 is the default) and these are held in the groups  vector in the task_struct  for each process. So long as a file has access rights for one of the groups that a process belongs to then that process will have appropriate group access rights to that file.

There are four pairs of process and group identifiers held in a processes task_struct :

uid, gid

The user identifier and group identifier of the user that the process is running on behalf of,

effective uid and gid

There are some programs which change the uid and gid from that of the executing process into their own (held as attributes in the VFS inode describing the executable image). These programs are known as setuid programs and they are useful because it is a way of restricting accesses to services, particularly those that run on behalf of someone else, for example a network daemon. The effective uid and gid are those from the setuid program and the uid and gid remain as they were. The kernel checks the effective uid and gid whenever it checks for privilege rights.

file system uid and gid

These are normally the same as the effective uid and gid and are used when checking file system access rights. They are needed for NFS mounted filesystems where the user mode NFS server needs to access files as if it were a particular process. In this case only the file system uid and gid are changed (not the effective uid and gid). This avoids an arcane situation where malicious users could send a kill signal to the NFS server. Kill signals are delivered to processes with a particular effective uid and gid.

saved uid and gid

These are mandated by the POSIX standard and are used by programs which change the processes uid and gid via system calls. They are used to save the real uid and gid during the time that the original uid and gid have been changed.

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中都有涉及.