我想使用 WinAPI 创建一个 Windows 互斥体，CreateMutex()并且OpenMutex(). 但出于安全考虑，我希望那些知道“密码”或硬编码魔术代码的进程打开互斥锁。我不希望每个进程都访问互斥锁。
例如，创建名为“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 之外什么都不做。）
你会让 Windows 创建一个新的 SID；不要尝试自己创建一个。使用该 SID，您可以构建一个 ACL（访问控制列表），授予对持有该 SID 的所有进程的访问权限，并（隐式）拒绝其他所有人该权限。然后可以将此 ACL 应用于互斥体，从而保护它。
现在要获得访问权限，您需要为该 SID创建一个模拟令牌。如果我了解 MSDN，则该过程是打开您的线程令牌，设置TokenUservia SetTokenInformation，然后应用修改后的令牌 via SetThreadToken。
现在在检查互斥锁的 ACL 时使用此模拟令牌。
MSDN 对创建有效用户 SID 的过程并不完全清楚；在上述过程中，可能需要将“User SID”替换为“Group SID”。