我想使用 WinAPI、CreateMutex() 和 OpenMutex() 创建一个 Windows 互斥锁。但是出于安全考虑，我希望那些知道“密码”或硬编码魔术代码的进程打开互斥锁。我不希望每个进程都访问互斥锁。
例如， 创建名为“Globel\cd689f00-0462-11e5-b939-0800200c9a66”的互斥锁。 所以只有知道互斥锁名称的进程才能访问这个互斥锁。但这不是一个好的解决方案，因为您可以简单地使用 Winobj.exe 并且您仍有机会找到该互斥体。 我希望这个互斥锁受到 ACL（访问控制列表）之类的保护。问题是，我找不到为 ACL 创建自己的 SID 的方法。
这是我所知道的和我想要的： 1. 我知道我可以通过将互斥锁命名为“Global\MyMutexName”来让许多进程访问它。 2.我也尝试了解MSDN上提到的ACL和SID。但是我仍然找不到创建自己的 SID 的方法（也许这没有意义？）。 3. 我不想将我的流程提升为管理员。
【问题讨论】：
您尝试执行的操作对于 Windows 使用的安全模型来说并不自然。始终根据运行可执行文件的人员授予权限，而不是根据可执行文件本身授予权限。但是，根据您的情况，可能会有合适的选择。
如果涉及的所有进程都在同一个用户的上下文中，那么您可以使用 IPC（例如，命名管道）来识别您的“友好”进程，并使用 DuplicateHandle() 将句柄传递给未命名的互斥体。进程。
如果进程必须在不同的用户上下文中，一种选择是让系统服务在特权上下文中运行以充当代理。当然，这需要以管理员权限安装系统服务，但这通常是可以接受的；只需执行一次。
如果应用程序必须是可移植的（无需安装，或者无需管理员权限即可安装）并且必须跨越用户边界，那么我认为您将不得不使用 IPC 来实现自己的互斥锁。当然，这样做效率很低。
请记住，在任何这些情况下，恶意用户仍然可以访问互斥锁 - 您能做的最好的事情就是稍微增加难度。例如，如果您使用实际的互斥锁，攻击者可以枚举其中一个进程的句柄，识别互斥锁并复制句柄。 （或者干脆将恶意代码注入一个所谓的“友好”进程中以直接使用句柄。）甚至 IPC 也可能被监视和复制。
您应该认真考虑边际安全收益是否值得显着增加复杂性。 IMO，不太可能。
（顺便说一句，正确的解决方案是让系统服务完成所有需要访问互斥锁的工作；用户运行的应用程序通常是一个瘦客户端，除了提供 GUI 之外什么都不做。）
【讨论】：
CreatePrivateNamespace。我稍后会尝试，如果我发现了什么，我会在这里更新。
你会让 Windows 创建一个新的 SID；不要尝试自己创建一个。使用该 SID，您可以构建一个 ACL（访问控制列表），授予对持有该 SID 的所有进程的访问权限，并（隐式）拒绝其他所有人该权限。然后可以将此 ACL 应用于互斥体，从而保护它。
现在要获得访问权限，您需要为该 SID 创建一个模拟令牌。如果我了解 MSDN，则该过程是打开您的线程令牌，通过SetTokenInformation 设置TokenUser，然后通过SetThreadToken 应用修改后的令牌。
现在在检查互斥锁的 ACL 时使用此模拟令牌。
MSDN 对创建有效用户 SID 的过程并不完全清楚；在上述过程中，可能需要将“User SID”替换为“Group SID”。
【讨论】：
SetThreadToken冒充获取互斥锁，释放互斥锁后需要使用RevertToSelf？
RevertToSelf。
SetTokenInformation 尝试直接更改令牌中的安全主体。我想它可能会起作用，但如果是这样，它肯定需要即使是管理用户也没有的特权。 （您可能还需要复制令牌并处理副本而不是已经使用的令牌。）由于 OP 不想被提升，这肯定不符合他的规范。