限制子进程访问共享内存和消息队列
Restrict child process access to shared memory and message queues
我正在编写一个服务器，它将接受在 运行 时间使用 Boost.DLL 加载的不受信任的动态库模块（DLL，SO/DSO）。
我想 运行 独立进程中的不受信任模块，该进程只能访问相关的共享内存（有时是只读的）和进程间队列。
Boost 允许 permissions 对象与共享内存相关联。
好像可以创建一个进程on windows and Linux，然后调整权限。
如何创建一个进程
- 没有开始的权限（例如，也许在 windows 上使用 AdjustTokenPrivileges？），但是
然后 - 被授予对共享内存映射文件的读取访问权限（例如，通过设置 permissions when constructing 共享内存段？）
或许这本身就太冒险了？
首先，来自文档：
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 由于其访问控制列表（未测试）将允许更细粒度的控制：它们应该允许您指定具有访问权限的 additional/different 帐户。
在linux上，很可能要实现这样的控制，需要额外的系统调用（例如要更改共享对象的owner/group and/or 添加这样一个组客户端用户帐户作为 primary/secondary 组）。
总结：_我会专注于向特定收件人授予访问权限，而不是 "starting a recipient without any permissions"。后者是不切实际的（进程甚至可能无法运行 "without any permissions"）并且在运行时提升权限比使用静态 assigned/administered 权限要困难得多。更不用说动态添加权限本质上不太安全。
我正在编写一个服务器，它将接受在 运行 时间使用 Boost.DLL 加载的不受信任的动态库模块（DLL，SO/DSO）。
我想 运行 独立进程中的不受信任模块，该进程只能访问相关的共享内存（有时是只读的）和进程间队列。
Boost 允许 permissions 对象与共享内存相关联。
好像可以创建一个进程on windows and Linux，然后调整权限。
如何创建一个进程
- 没有开始的权限（例如，也许在 windows 上使用 AdjustTokenPrivileges？），但是 然后
- 被授予对共享内存映射文件的读取访问权限（例如，通过设置 permissions when constructing 共享内存段？）
或许这本身就太冒险了？
首先，来自文档：
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 由于其访问控制列表（未测试）将允许更细粒度的控制：它们应该允许您指定具有访问权限的 additional/different 帐户。
在linux上，很可能要实现这样的控制，需要额外的系统调用（例如要更改共享对象的owner/group and/or 添加这样一个组客户端用户帐户作为 primary/secondary 组）。
总结：_我会专注于向特定收件人授予访问权限，而不是 "starting a recipient without any permissions"。后者是不切实际的（进程甚至可能无法运行 "without any permissions"）并且在运行时提升权限比使用静态 assigned/administered 权限要困难得多。更不用说动态添加权限本质上不太安全。