06-文件系统用户ID和组ID

9.5　文件系统用户ID和组ID

在Linux系统中，要进行诸如打开文件、改变文件属主、修改文件权限之类的文件系统操作时，决定其操作权限的是文件系统用户ID和组ID（结合辅助组ID），而非有效用户ID和组ID。（和其他UNIX实现一样，有效用户ID和组ID仍在使用，其用途在前面章节已有论述。）

通常，文件系统用户ID和组ID的值等同于相应的有效用户ID和组ID（因而一般也等同于相应的实际用户ID和组ID）。此外，只要有效用户或组ID发生了变化，无论是通过系统调用，还是通过执行set-user-ID或者set-group-ID程序，则相应的文件系统ID也将随之改变为同一值。由于文件系统ID对有效ID如此的“亦步亦趋”，这意味着在特权和权限检查方面，Linux实际上跟其他UNIX实现非常类似。只有当使用Linux特有的两个系统调用（setfsuid() 和setfsgid()）时，才可以刻意制造出文件系统ID与相应有效ID的不同，因而Linux也不同于其他的UNIX实现。

那么，Linux为什么要提供文件系统ID呢？在何种情况下，需要使有效ID有别于文件系统ID呢？这主要是由于历史原因造成的。文件系统ID始见于Linux 1.2版本。在该版本的内核中，如果进程某甲的有效用户ID等同于进程某乙的实际用户ID或者有效用户ID，那么发送者（某甲）就可以向目标进程（某乙）发送信号。这在当时影响到了不少程序，比如Linux NFS（网络文件系统）服务器程序，在访问文件时就好像拥有着相应客户进程的有效ID。然而，如果NFS服务器真地修改了自身的有效用户ID，面对非特权用户进程的信号攻击，又将不堪一击。为了防范这一风险，文件系统用户ID和组ID应运而生。NFS服务器将有效ID保持不变，而是通过修改文件系统ID伪装成另一用户，这样既达到了访问文件的目的，又避免了遭受信号攻击。

自内核2.0起，Linux开始在信号发送权限方面遵循SUSv3所强制规定的规则，且这些规则不再涉及目标进程的有效用户ID（参考20.5节）。因此，从严格意义上来讲，保留文件系统ID特性已无必要（如今，进程可以根据需要，审慎而明智地利用本章稍后介绍的系统调用，使以非特权值对有效用户ID的赋值来去自由，以实现预期结果），但为了与现有软件保持兼容，这一功能得以保留了下来。

由于文件系统ID实属异类，且一般都等同于相应的有效ID，本书后续部分在述及各种文件权限的检查，以及设置新文件的属主时，通常将根据进程有效ID来加以解释。即使是出于Linux系统的目的而真地使用了进程的文件系统ID，但在实践中，这些标识的存在与否并不会带来显著差别。