共享内存的访问控制

发布于 2024-10-06 10:23:44 字数 697 浏览 0 评论 0原文

我想这个问题是针对 Linux/Unix 系统编程专家的(不幸的是我还不是那种人;))。

我正在构建一个在 Linux/Unix 多核机器上运行的系统,其中进程通过共享内存相互通信(速度很重要 - 尽可能减少对内核的调用)。 当一个进程请求与另一个进程通信时,会动态创建用于通信的共享内存“通道” - 每个进程都有一个侦听线程,该线程正在接收并“接受”这些请求,然后创建/初始化共享内存通道。对于进程ab,创建两个通道(共享内存区域) - 一个通道用作a的“输出”和“输入” " 到 b ,反之亦然。

创建通信通道时,进程 a 必须对其相应的“输出”通道具有 R/W 访问权限,并且对其相应的“输入”通道仅具有 R 访问权限。其他进程必须无法获得对其他进程对之间共享的通道的 W 访问权限(最好它们甚至不应该具有 R 访问权限)。

您能建议什么解决方案?

我正在考虑:

  1. 定义我自己的系统调用(目前不优选)
  2. 使用文件系统固有的文件权限来

来强加此访问权限对于第二个解决方案,想法是在不同的用户ID下运行进程并使用动态创建为每个进程对进行分组,并相应地为每个共享内存描述符分配文件权限(R 为组,R/W 为写入进程,- 为其余进程)。

第二种方案可行吗?是否有更好的解决方案(例如,涉及一些我不知道的系统调用)?

非常感谢您的时间和帮助。

I guess this question is directed at Linux/Unix system programming experts (unfortunately I am not one of that kind, yet ;)).

I am building a system, which runs on Linux/Unix, multi-core machine, in which processes communicate with each other through shared memory (speed is important - minimum calls into the kernel as possible).
Shared memory "channels" for communication are dynamically created when a process requests to communicate with another one - each process has a listening thread that is receiving and "accepting" these requests and then creating/initializing shared memory channels. For processes a and b, two channels (shared memory regions) are created - one channel is used as "output" from a and "input" to b and the other vice versa.

When the communication channels are created it is imperative that process a has R/W access to its corresponding "output" channel and only R access to its corresponding "input" channel. Other processes must not be able to obtain W access to the channels shared between other pairs of processes (preferably they should not even have R access).

What solution can you suggest?

I was thinking about:

  1. defining my own system calls (not preferable at the moment)
  2. using file permissions inherent to the file-system to impose this access rights

For the 2nd solution, idea is to run processes under different user IDs and use dynamic creation of groups for each process pair and assigning file permission to each shared memory descriptor accordingly (R to group, R/W to the writer process, - to the rest).

Is the 2nd solution feasible? Are there any better solutions (e.g. which involve some system calls am I not aware of)?

Thank you very much for your time and help.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

感性 2024-10-13 10:23:44

您不能使用组来执行此操作,因为无法将补充组添加到已经运行的进程中。然而,基于用户的机制可以正常工作。

每个进程都在其自己的 uid 下运行。为了创建共享内存通道,发送端使用shm_open()创建一个共享内存对象,并指定O_RDWR | O_CREAT | O_EXCL 和模式 0600。因此,它是唯一打开的进程,并且只有其 uid 才允许打开它。然后,发送方打开同一共享内存段的第二个文件描述符,这次使用 O_RDONLY。它通过 unix 域套接字使用 SCM_RIGHTS 消息将第二个只读文件描述符发送到接收进程。然后它可以关闭只读文件描述符。

发送进程和接收进程然后mmap()共享内存。接收进程具有只读访问权限,并且无权将其升级为读写权限。其他进程根本无法打开它。

You cannot use groups to do this, because it isn't possible to add supplementary groups to an already-running process. However, the user-based mechanism will work fine.

Run each process under its own uid. To create a shared memory channel, the sending side creates a shared memory object with shm_open(), specifying O_RDWR | O_CREAT | O_EXCL and mode 0600. Thus it is the only process with it open, and only its uid is allowed to open it. The sending side then opens a second file descriptor for the same shared memory segment, this time using O_RDONLY. It sends this second, read-only file descriptor to the receiving process, using a SCM_RIGHTS message over a unix domain socket. It can then close the read-only file descriptor.

The sending process and recieving process then mmap() the shared memory. The receiving process has read-only access, and does not have the rights to upgrade it to read-write. No other processes can open it at all.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文