基于 UNIX 应用程序的子系统中的 setuid

setuid 和 setgid

基于 UNIX 应用程序的子系统及标识

在基于 UNIX 应用程序的子系统中设置 setuid 的注意事项

使用 setuid 和 setgid 机制，程序在运行时可以采用安全主体的某些方面，而不采用运行该程序的用户的安全主体。它们可让程序在调用用户和另一个安全主体的特定方面之间进行替换。

适当权限与此明显不同。然而使用 setuid 和 setgid 机制，应用程序可以控制问题“您是谁？”的答案，回答该问题“您可以做什么？”的适当权限

在典型的 UNIX 环境中，确实有一个用户被授予给所有的权限。该用户一般称为 root，带有 uid == 0。在基于 UNIX 应用程序的子系统中，给定系统上所有支持的权限都授予了该系统管理员组或 Domain管理员组中的成员用户。不需要以管理员身份登录。任何具有管理员组或 Domain管理员组成员身份的用户都拥有 root 权限。并非 POSIX 或 UNIX 中定义的所有权限都可以在 SUA 中使用，也就是说，有些特定权限不会授予给任何用户。

通常多种操作需要适当权限。这些操作包括访问文件系统、向其他进程（进程控制）发送信号，或者更改进程的有效用户标识符 (UID) 或组标识符 (GID)，以便更改该进程执行特定操作的能力。

根据 POSIX 标准，文件具有的权限包括设置 UID (setuid) 和设置 GID (setgid) 的位。如果对某个文件设置了其中一种或两种位，且有进程运行该文件，则该进程会获得该文件的 UID 或 GID。如果谨慎使用，这种机制允许非权限用户运行使用该文件所有者或组的较高权限运行的程序。但是，如果使用不正确，允许非权限用户执行本应只由管理员执行的操作可能会引发安全风险。因此，默认情况下，SUA 不支持此机制。然而，如果尝试运行设置了 setuid 或 setgid 位的文件，SUA 将不运行该文件而是返回错误代码 ENOSETUID。

如果依赖需要标准 POSIX 行为的应用程序，可以将 SUA 配置为运行已设置 setuid 或 setgid 位的文件。如果按这种方式配置了 SUA，当进程运行已设置 setuid 或 setgid 位的文件时，SUA 会为具有指定给该文件所有者或组的权限的进程构造本地安全令牌。由于这些标记是本地的，因此网络上的其他计算机无法识别。例如，这意味着即使该文件归 Domain管理员组的成员所有，该进程也不会拥有通过 Microsoft(R) Windows(R) 网络访问域中其他计算机的受信任权限。相反，这些权限将会仅在运行该进程的计算机上有效。

例如，某个进程运行设置了 setuid 位且归域管理员组成员所有的程序文件。如果该程序尝试更改域用户的密码，更改操作将会失败，因为进程的安全令牌是本地的，因此无法由域中的其他系统识别。从另一方面说，如果该程序尝试更改本地用户的密码，更改操作将会成功，因为文件的所有者是 Domain管理员组的成员，而该组通常属于本地计算机的管理员组。有关如何配置 SUA 以运行设置了 setuid 或 setgid 位的文件的详细信息，请参阅随 Utilities and Software Development Kit (SDK) for UNIX-based Applications 下载包一起提供的帮助文件。

对于 setuid(2)、setgid(2) 和 chroot(2) 函数，进程必须具有映射回系统帐户、本地域管理员帐户或主体域管理员帐户的有效 UID。本地管理员帐户只能将同一域中的 UID 或 GID 更改为其他 ID。

对于 chown(1)、chmod(1) 和 chgrp(1)，帐户必须具有 Windows 权限 SE_BACKUP 和 SE_RESTORE，才能对归其他用户或组所有的文件执行 make 操作，或对归其他用户所有的文件权限进行修改。通常这些权限属于管理员帐户和备份操作员帐户。