在 Unix 中，当代表某个用户执行某些操作时，系统程序通常会调用 seteuid(UID) (附带 setegid())首先切换到该用户，执行该操作，然后在完成后切换回 super 用户使用 seteuid(0)。我对 seteuid() 进行计时，它的时间约为一到几微秒(这意味着，相对于需要完成的操作(如操作文件或运行 CGI 程序)，它的成本相当低)。
我不熟悉Windows API。我们是否在 Windows 上做同样的事情(但使用 ImpersonateLoggedOnUser() + RevertToSelf() API 函数)？一般来说，这些函数的速度有多快？
最佳答案
它基本上是相同的，但有一个重要的区别需要记住:您提到的 Windows API 需要有效 token 的句柄。
换句话说，即使以 SYSTEM(或任何具有 SeTcbPrivilege 的进程)身份运行，您也需要模拟登录用户。
用户可以通过多种方式登录:
- 与物理计算机交互
- 通过远程桌面 session
- 几乎所有 Microsoft 网络连接，例如文件共享、名称管道、邮槽、RPC 以及构建在其上的所有其他连接。
大多数情况下，创建进程会使其继承当前 token 。
您是否在 IIS 中使用 Kerberos、NTLM 或者 HTTP BASIC 身份验证并不重要。这一切都经过 Windows 身份验证，因此您会获得一个 token 。另一方面，Tomcat 中的 HTTP BASIC 身份验证不会为您提供 Windows token ，因此无法进行模拟。
现在是棘手的部分。
仔细想想， token 实际上只是一个带有用于授权 (DACL) 和审核 (SACL) 的访问控制列表的内存结构。它是由 Authentication Package 创建的(美联社)。创建 token 的是 AP。有点像 Unix 中的 PAM，AP 可以用自定义代码替换。
事实上，存在一个开源 setuid 身份验证包。将 CVS 移植到 Windows NT 的人们编写了一个 AP，creates a token out of thin air ，只要您拥有 SeTcbPrivilege(相当于 root)。我从未尝试过，但它可以在本地计算机上为不在场的用户提供 token 。该代码相当旧(它只会创建提升的代币)，但除此之外，它是 LGTM。没有身份验证，不涉及密码或智能卡，因此使用该组成的 token 运行的进程将无法使用它来向另一台计算机进行身份验证。
总结:
- 总体思路是一样的
- 如果您遵守规则，您将只能模拟已登录的用户，无论登录过程或位置如何
- 您可以改变这种行为，但它
- 模拟在 Unix 和 Windows 中可能同样快，因为内部工作原理大致相似。您很可能不会注意到其中的差异。
建议:我的 Programming Windows Security 副本咖啡泛黄了，便利贴卡在外面，还有撕破的纸页。关于该主题的最佳文本，如果您想了解 Windows 安全性，则必须阅读。
关于windows - Windows 的 ImpersonateLoggedOnUser() + RevertToSelf() 与 Unix 的 seteuid() + setegid() 的速度，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12299455/