c++ - 限制子进程访问共享内存和消息队列

Question

我正在编写一个服务器，它将接受在运行时使用 Boost.DLL 加载的不受信任的动态库模块(DLL、SO/DSO) .

我想在一个单独的进程中运行不受信任的模块，该进程只能访问相关的共享内存(有时是只读的)和进程间队列。

Boost 允许 permissions与共享内存关联的对象。

似乎有一种方法可以创建进程 on windows和 Linux然后调整权限。

如何创建一个流程

• 没有开始的权限(例如，也许在 Windows 上使用 AdjustTokenPrivileges？)，但是
• 然后被授予对共享内存映射文件的读取访问权限(例如，当 permissions 是共享内存段时，通过设置 constructing？)

或许这本身就太冒险了？

Answer 1

首先，来自文档:

Named resources offered by Boost.Interprocess must cope with platform-dependant permission issues also present when creating files. If a programmer wants to shared shared memory, memory mapped files or named synchronization mechanisms (mutexes, semaphores, etc...) between users, it's necessary to specify those permissions. Sadly, traditional UNIX and Windows permissions are very different and Boost.Interprocess does not try to standardize permissions, but does not ignore them.

All named resource creation functions take an optional permissions object that can be configured with platform-dependant permissions.

当心，如果你这样做，那么你必须立即了解平台特定所需的权限:

Since each mechanism can be emulated through different mechanisms (a semaphore might be implement using mapped files or native semaphores) permissions types could vary when the implementation of a named resource changes (eg.: in Windows mutexes require synchronize permissions, but that's not the case of files). To avoid this, Boost.Interprocess [usually¹, red.] relies on file-like permissions, requiring file read-write-delete permissions to open named synchronization mechanisms (mutex, semaphores, etc.) and appropriate read or read-write-delete permissions for shared memory. This approach has two advantages: it's similar to the UNIX philosophy and the programmer does not need to know how the named resource is implemented.

¹ 当不传递权限对象时

---

您的其他问题:

• 没有开始的权限(例如，也许在 Windows 上使用 AdjustTokenPrivileges？)，但是
• 然后被授予对共享内存映射文件的读取访问权限(例如，通过在构造共享内存段时设置权限？)

没有。 permissions 对象不向调用进程授予权限。 permissions 对象限制 其他进程的访问。我敢打赌，只有在 create_only 或 open_or_create 上指定 permissions 才有意义。

我想象的是在 Windows/Linux 上通常的路线:

• 您以特定用户帐户启动服务器
• 您使用同一个帐户启动客户端
• 您创建的 IPC 对象只能从创建它们的帐户(所有者)访问

我敢打赌，由于其访问控制列表(未对此进行测试)，Windows 将允许进行更细粒度的控制:它们应该允许您指定具有访问权限的其他/不同帐户。

在 linux 上，很可能要实现这种控制，需要额外的系统调用(例如，更改共享对象的所有者/组和/或将客户端用户帐户添加为主要/次要组) .

总结:_我会专注于向特定收件人授予访问权限，而不是“在没有任何权限的情况下启动收件人”。后者是不切实际的(进程甚至可能“没有任何权限”就无法运行)，并且在运行时 boost 权限比使用静态分配/管理的权限要困难得多。更不用说动态添加权限本质上不太安全。