c - 如果我使用 "Local\"，我是否需要担心 CreateMutex 的拒绝服务？

Question

我想使用 CreateMutex作为将我的应用程序限制为单一实例的一种手段。 (具体来说，每个用户一个实例。)

The MSDN documentation to CreateMutex 警告恶意用户首先抢夺和囤积互斥锁的可能性。但是，如果我使用 session 命名空间(通过“Local\”前缀)创建互斥锁，这仍然是我需要关注的事情吗？如果是这样，在什么情况下不同的用户可以在我的 session 中创建互斥锁？

Answer 1

使用 Local\命名空间将使互斥锁与当前桌面 session 保持隔离，但您还应该遵循该段中的其他建议:

To prevent this situation, create a randomly named mutex and store the name so that it can only be obtained by an authorized user. Alternatively, you can use a file for this purpose. To limit your application to one instance per user, create a locked file in the user's profile directory.

使用类似 CoCreateGuid 的名称生成互斥锁名称，将其存储在注册表项中并使用它，或者将文件锁定在用户的配置文件目录中。

建议使用难以猜测的 ID 的原因是，在属于不同用户的多个进程在同一个 session 中运行的不太可能的情况下，您的进程具有使用可以保护的难以猜测的 key 名称的机制通过使用注册表 ACL 机制从另一个帐户获取 - 即阻止其他非管理用户读取该值在这种情况下保持安全。在使用锁定文件作为主目录上的默认 ACL 的情况下，您将获得类似的保护，这将阻止其他用户创建或修改文件 [*]。我再次声明，这实际上是一种不太可能发生的情况，但它是可能的(可以使用与在特定 session 中登录的用户不同的用户凭据从系统服务启动进程)。

您是否试图将其限制为“每个用户一个实例”或“每个桌面 session 一个实例”？

如果是每个 session 一个，那么 Local\互斥锁是合适的。

如果它是每个用户一个(不管 session )，那么锁定用户配置文件目录中的文件更合适。

您可以将 Windows 配置为允许使用相同用户名登录多个远程终端服务 - 默认情况下，每个用户一个 session 。

[*] 如果用户使用您的凭据或管理员凭据运行，所有这些机制都无效，因为他们只能读取此 key 。这个想法是保护在同一 session 中运行的其他帐户