如何避免使用共享内存和信号量与其他程序发生冲突答案

【问题标题】：How to avoid conflicts with other programs using shared memory and semaphore如何避免使用共享内存和信号量与其他程序发生冲突
【发布时间】：2011-05-27 00:58:09
【问题描述】：

我的程序使用共享内存并用信号量保护它以与同一程序的其他实例进行通信。我担心共享内存和信号量的安全性。

如何确保我使用的信号量和 shm 不会被其他会搞砸的程序打开？有一种方法可以在具有自己的用户组的单独用户下运行程序，并通过限制共享对象只能由该用户和组访问来保护共享对象。这是我问题的答案，还是有一些陷阱，可能在 Windows 上？
如果我必须在同一用户下运行所有程序，或者如果某些程序以 root 身份运行（总是有这样的程序，不是吗），有什么方法可以保护它们吗？
我开始为希望一起通信的所有实例设置 shm 和信号量的默认“密钥”。但是可能有不同的程序已经使用了“密钥”。有什么技术可以解决这样的问题吗？我正在考虑选择一个“键”范围（即键将是 1000 - 2000 范围内的整数），如果程序无法获取默认值的键，它会尝试从该范围中获取其他键。

我找到了相关问题here，但它并没有说明我的问题 2 和 3。除了那个问题之外，我找不到任何与 shm 和信号量冲突和保护相关的内容，似乎用处不大在编写程序时考虑。

我的情况是我有一个程序想要与同一程序的其他实例进行通信。存在运行同一程序的多个实例的“组”，其中一个“组”的程序一起通信，而另一个“组”中的程序一起通信。它们通过受信号量保护的共享内存进行通信。程序可以在各种 *nix 平台和 Windows 上运行。它们应该在几年内 24/7 全天候运行，并且应该可靠且安全，这就是我担心这些冲突的原因。

【问题讨论】：

标签： c++ ipc semaphore shared-memory conflict

【解决方案1】：

仅当所有使用共享内存的程序都在协作时，信号量才“保护”共享内存。 IE。它允许想要玩得很好的程序不破坏共享对象。

但是，这并不能保证恶意程序能够跳入并破坏共享结构，如果它愿意的话。我不知道 C++ 标准中有任何与安全相关的功能，因此我建议使用特定于操作系统的方法。

这意味着您可能需要在 Linux、Windows、Mac 等（无论是您的目标平台）上使用不同的代码，甚至可能需要在不同的操作系统版本上使用不同的代码。

【讨论】：

是的，我已经有针对不同平台的特定于操作系统的部分代码，因为使用共享内存和信号量的不同函数调用是必需的。问题是 - 保护内存/信号量不被其他程序意外访问的技巧是什么？
在 Windows 上，您应该查看 SECURITY_ATTRIBUTES。这个结构用于CreateSemaphore和CreateFileMapping（用于shared memory）

【解决方案2】：

如果您主要关心的是冲突，那么使用 GUID 作为名称怎么样？没有人（在我们有生之年）会偶然想到这个{897917A3-D44E-4f0d-A458-1318152CCCDA}。

关于防止恶意软件，我会利用操作系统中的安全机制。要求服务在某个用户的范围内运行，然后限制对外部对象（如信号量和共享内存）的访问仅限于该用户。只要该用户的安全没有被破坏，那么您的系统就应该是安全的。

在 Windows 上，您通常在创建信号量和文件映射时使用 SECURITY_ATTRIBUTES 结构，在 Unix 上使用 mode_t（使用 creat/open/chmod/etc）。

不要应用默默无闻的安全方法，让名称“难以猜测”并相信它们是秘密的。它只会有助于不干扰同一系统上的其他应用程序。它不会阻止恶意用户/代码，因为对象的名称可能不是秘密。

【讨论】：

谢谢。不幸的是，我不能像在 *nix 上那样使用 GUID 字符串，由于一些限制，我不得不使用 shmget() 和 semget()，它们接受 key_t（它是 int）作为参数。
啊...我忘记了 Unix 中的信号量。自 2000 年左右以来，我就没有使用过 Unix。为什么不让一个进程随机选择一个免费的信号量密钥，并将其存储在共享内存中。然后其他进程可以通过共享内存获取信号量句柄。当然，在读取信号量键时，您必须采用某种锁定机制来保护其他进程免受竞争条件的影响。