如何为从 Apache 启动的子进程禁用 SELinux？
我的 Apache 模块 启动一个辅助子进程，该子进程执行以下操作（例如但不限于以下操作）
- ：一个套接字，以便它可以与 Apache 通信。
- 在 Apache 退出时删除的临时位置中读取和写入文件。这些文件用于存储通过网络接收的大量数据，以防数据无法轻松装入 RAM。
- 它生成用户指定的可执行文件。类似于CGI。每个生成的进程都作为自己的专用用户运行。
帮助程序子进程以 root 身份启动，以便它可以管理文件所有权和权限，并可以作为特定用户生成更多进程。
我的模块的一些用户在安装了 SELinux 的系统上运行，例如基于 RedHat 的发行版。 SELinux 通常会干扰我的模块。到目前为止，我一直告诉人们在系统范围内禁用 SELinux，因为我不知道如何为我的软件编写正确的策略。文档非常分散、复杂，通常只针对系统管理员，而不是软件开发人员。
作为朝着正确方向迈出的一步，我想实现对 SELinux 的最低限度的支持。我正在寻找一种方法来启动我的辅助子进程，而无需任何 SELinux 限制，而无需在系统范围内禁用 SELinux。有没有办法做到这一点，如果有的话，怎么做？
My Apache module launches a helper subprocess which does, for example, but not limited by, the following things:
- It sets up a socket so that it can communicate with Apache.
- Reads and writes files in a temporary location that is deleted when Apache exits. These files are used e.g. for storing large amounts of data received over the network, in case that data does not comfortably fit in RAM.
- It spawns user-specified executables. Similar to CGI. Each of these spawned processes are run as their own dedicated user.
The helper subprocess is launched as root so that it can manage file ownerships and permissions and can spawn more processes as specific users.
Some users of my module run on systems with SELinux installed, e.g. RedHat-based distros. SELinux usually interferes with my module. Until now I've been telling people to disable SELinux system-wide because I can't figure out how to write a proper policy for my software. Documentation is very scattered, complex and usually only targets system administrators, not software developers.
As a step into the right direction, I want to implement minimal support for SELinux. I'm looking for a way to launch my helper subprocess without any SELinux constraints without disabling SELinux system-wide. Is there a way to do that, and if so, how?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
嗯...您可以编写一条规则将您的域转换为
unconfined_t，但是这样您就会惹恼很多系统管理员。最好自己编写一个继承自httpd_t的新域，并添加适当的访问上下文。Well... you could write a rule that transitions your domain to
unconfined_t, but then you'd piss off quite a few sysadmins. Best to write yourself a new domain that inherits fromhttpd_tand also adds the appropriate contexts for access.