如何使用共享内存和信号量避免与其他程序发生冲突
我有一个程序，它使用共享内存并使用信号量保护它，以便与同一程序的其他实例进行通信。我担心共享内存和信号量的安全性。
如何确保我使用的信号量和 shm 不会被其他程序打开而造成混乱？有一种方法可以在单独的用户及其自己的用户组下运行程序，并通过限制共享对象只能由该用户和组访问来保护共享对象。这是我的问题的答案，还是有一些陷阱，也许在 Windows 上？
如果我必须在同一用户下运行所有程序，或者某些程序以 root 身份运行（总有这样的程序，不是吗），是否有某种方法可以保护它们？
我开始为 shm & 设置默认“密钥”。所有想要一起通信的实例的信号量。但可能有不同的程序已经获取了“密钥”。有什么技术可以解决这样的问题吗？我正在考虑选择一系列“键”（即键将是 1000 - 2000 范围内的整数），如果程序无法获取默认值的键，它会尝试从该范围中获取其他键。
我在此处找到了相关问题，但它没有说明我的任何情况问题2和3。除了这个问题我找不到任何与shm和信号量冲突和保护相关的内容，似乎在编写程序时没有考虑太多。
我的情况是，我有一个程序想要与同一程序的其他实例进行通信。同一程序运行多个实例“集合”，其中一个“集合”中的程序一起通信，而其他“集合”中的程序一起通信。它们通过信号量保护的共享内存进行通信。程序可以在各种 *nix 平台上运行，也可以在 Windows 上运行。它们应该全天候 (24/7) 启动并运行几年，并且应该可靠且安全，这就是我担心冲突的原因。
I have program that uses shared memory and protects it with semaphore to communicate with other instances of the same program. I am concerned about security of my shared memory and semaphores.
How can I ensure that semaphore and shm that I use won't be opened by other program that will mess it up? There is one way of running the program under separate user with his own usergroup and protecting shared objects with restricting them to be accessible only by that user and group. Is that the answer to my question, or are there some pitfalls, maybe on windows?
Is there some way to protect them if I have to run all programs under same user, or if some programs are run as root (there are always such programs, aren't they)?
I started up with setting a default 'key' for shm & semaphore for all the instances that want to communicate together. But there could be different program that has taken the 'key' already. Is there some technique to solve such problem? I was thinking about selecting a range of 'keys' (ie. key would be integer in range 1000 - 2000) where if program is unable to acquire key of default value it tries to get other key from the range.
I found related question here, but it does not say anything about my questions 2 and 3. Other than that question I can't find anything related to shm and semaphore conflicts and protection, seems like it is not taken much into account when writing programs.
My situation is that I have a program that wants to communicate with other instances of the same program. There are run multiple 'sets' of instances of the same program, where programs of one 'set' communicate together, and programs in other 'set' communicate together. They communicate through semaphore protected shared memory. Program is run on various *nix platforms and on windows too. They should be up and running 24/7 for few years and should be reliable and safe, that's the reason I'm concerned about the conflicts.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
仅当使用共享内存的所有程序都进行协作时，信号量才会“保护”共享内存。即它允许想要良好运行的程序不破坏共享对象。
然而，这并不能保证恶意程序能够根据需要跳入并破坏共享结构。我不知道 C++ 标准中有任何与安全相关的功能，因此我建议采用特定于操作系统的方法。
这意味着您可能需要在 Linux、Windows、Mac 等（无论您的目标平台）上有不同的代码，甚至可能在不同的操作系统版本上有不同的代码。
The semaphores "protect" the shared memory only if all the programs using it are collaborating. I.e. it allows the program which wants to play nicely not to corrupt the shared objects.
This however doesn't guarantee that a malicious program will be able to jump in and corrupt the shared structures if it wants to. I don't know of any security-related features in C++ standard, therefore I would suggest to resort to OS-specific means.
This means that you might need to have different code on Linux, Windows, Mac etc. (whichever are your target platforms), maybe even different code on different OS versions.
如果您主要担心的是冲突，那么使用 GUID 作为名称怎么样？没有人（在我们的一生中）会偶然想出这个
{897917A3-D44E-4f0d-A458-1318152CCCCDA}。至于针对恶意软件的防护，我会利用操作系统中的安全机制。要求服务在某个用户的范围内运行，然后将对外部对象（例如信号量和共享内存）的访问限制为仅限该用户。只要该用户的安全不被破坏，那么您的系统就应该是安全的。
在 Windows 上，当您创建信号量和文件映射以及 mode_t（使用
creat/open/chmod/etc) 在 Unix 上。不要应用“模糊安全”方法，即使名称“难以猜测”并相信它们是秘密的。它只会有助于不干扰同一系统上的其他应用程序。它不会阻止恶意用户/代码，因为对象的名称可能不是秘密。
If your main concern is about conflicts, how about using a GUID as a name? Nobody (within our life times) will ever come up with this
{897917A3-D44E-4f0d-A458-1318152CCCDA}by chance.As for protection against malicious software, I'd utilize the security mechanisms in the operating system. Require services to run within the scope of some user, and then restrict access to external objects such as semaphores and shared memory to that user only. As long as the security of that user isn't breached, then your system should be safe.
On Windows you'd typically use the
SECURITY_ATTRIBUTESstructures when you create the semaphore and file mapping, and mode_t (withcreat/open/chmod/etc) on Unix.Don't apply the method of security by obscurity, by making the names "hard to guess" and believe they are secret. It will only help to not interfer with other applications on the same system. It will not stop malicious users/code, since the names of the object may not be a secret.