process credentials

转载于:  http://www.wowotech.net/process_management/19.html

一、介绍

当linux系统中的一个进程运行起来的时候，总是要访问系统的资源，访问文件或者向其他的进程发送信号。系统是否允许其进行这些操作？系统是根据什么来判断该进程的权限？这些问题是和进程信任状（process credentials）相关。

process credentials包括一系列的ID，如下：

1、real user ID 和 real group ID

2、effective user ID 和 effective group ID

3、saved set-user-ID 和 saved set-group-ID

4、file-system user ID 和 file-system group ID

5、supplementary group IDs

 

二、什么是real user ID 和 real group ID

real user ID 和 real group ID标识了该进程属于哪一个用户（哪一个组）。Swapper和init进程的real user ID 和 real group ID都被设定为root（ID=0），用户登陆后，其对应的shell进程的real user ID 和 real group ID会被设定为登录用户。这是login进程调用setuid函数设定的。在fork进程的时候，子进程的credentials是继承自其父进程。

 

三、什么是effective user ID 和 effective group ID

就如同其命名，真正去检查一个进程是否有权限进行某些动作（例如访问IPC对象、通过系统调用请求内核服务等）的是effective user ID 和 effective group ID。一般而言，effective user ID（effective group ID）是和real user ID（real group ID）一样的，但是如果可执行文件设定了Set-User-ID（Set-Group-ID），那么在进程创建的时候，其effective user ID 和effective group ID则分别等于该可执行文件的user ID。

 

四、什么是saved set-user-ID 和 saved set-group-ID

Linux kernel中的task_struct中定义了这些ID如下：

uid_t uid,euid,suid,fsuid;

gid_t gid,egid,sgid,fsgid;

这里的suid（sgid）表示了saved set-user-ID（saved set-group-ID），这里的变量命名非常不友好，表面看起来是save了real ID，但实际上是save了effective ID。为何要save effective ID？其实这是和一个准则相关的：一个进程应该以尽可能小的权限运行。大部分的嵌入式软件工程师都会忽略这一点，因为嵌入式系统基本不是多用户的，开发者都是用root登录进入系统，全部掌管一切。此外，saved set-user-ID（saved set-group-ID）是和Set-User-ID（Set-Group-ID）相关的。例如张三启动一个owner是root的可执行程序，并且该程序设定了Set-User-ID bit，那么，当该程序执行的时候，real user ID是张三，effective user ID是root，saved set-user-ID由于是copy自effective user ID，因此也是root。该进程并不是总是需要root权限，因此，基于进程应该以尽可能小的权限运行的准则，在不需root权限的时候可以通过系统调用修改effective user ID为张三（对于unprivileged的用户，effective user ID只能在real user ID和saved set-user-ID之间切换）。而在需要root权限的时候，可以通过系统调用修改effective user ID回root。正因为如此，进程才需要一个saved set-user-ID来保存原始的effective user ID。

同样的道理适用于saved set-group-ID，这里不再赘述。

 

五、什么是file-system user ID 和 file-system group ID

这个ID是linux特有的，传统的unix并没有这个ID。对于传统的unix，访问文件、发送signal，打开IPC的object等等的权限都是依据effective ID判断。对于linux，其余的权限仍然依据effective ID判断，但是对于文件的访问则使用file-system user ID 和 file-system group ID（当然，需要配合supplementary group IDs）。

在linux kernel中，file-system user ID（file-system group ID）都是跟随effective user ID（effective group ID）。例如，如果owner是root的可执行文件如果设定了Set-User-ID bit，那么，当该程序执行的时候， effective user ID是root，file-system user ID也跟随effective user ID被设定为root。如果通过系统调用修改effective user ID，file-system user ID也会随之修改。这样就保证了linux的权限判断和传统的unix是一样的。不一样的地方在于linux提供了两个特别的系统调用setfsuid() 和setfsgid()来设定进程的file-system user ID和file-system group ID。

为何linux要引入file-system user ID 和 file-system group ID？这是和NFS (Network File System)相关的。考虑下面的场景：运行NFS server进程的A主机开放其文件系统，运行NFS client进程的B主机可以通过mount NFS file system象访问本地文件那样访问A主机的文件。在这样的场景下，NFS client进程访问A主机上的文件当然应该应用NFS client的effective ID，但是由于是网络文件系统，实际访问文件的是NFS server进程。如果修改NFS server的effective ID的话，用户空间的进程可以通过向NFS server发送signal来攻击。解决这个问题有两个思路：

1、  不修改effective ID，引入file-system user ID（file-system group ID）

2、  修改effective ID，改变信号发送的机制。也就是当A进程发送信号给B进程，该操作是否允许不再和B进程的effective ID相关。

在linux kernel的早期版本采用了方案一，但是2.0之后的kernel版本采用了方案二。因此，file-system user ID 和 file-system group ID应该是被废弃的，但是，为了软件的兼容性，linux kernel仍然保留了这两个file-system ID。

 

六、什么是supplementary group IDs

当一个用户登录后，loggin程序（其user ID是root）会根据/etc/passwd(还有/etc/shadow)中的信息来校验密码，并设定该登录用户的shell进程的user ID和第一个group ID。由于一个用户ID可能属于多个group，通过/etc/group文件，loggin程序可以知道该用户还属于哪些group，并设定该登录用户的shell进程的supplementary group IDs。

当用户通过shell创建新的进程的时候，子进程的supplementary group IDs是继承自其父进程。supplementary group IDs会配合file-system ID和effective ID来进行进程是否有访问某些资源权限的判定。

转载于:https://www.cnblogs.com/tureno/articles/6155956.html