【问题标题】:Using posix_spawn() with setuid() & setgid()将 posix_spawn() 与 setuid() 和 setgid() 一起使用
【发布时间】:2020-05-01 14:36:03
【问题描述】:

在我的 glibc 2.13 版本中似乎存在一个错误,它使重复调用 fork()/execv() 很危险,从而导致崩溃和内存损坏。这似乎发生在大约 1-2% 的时间里。目前的代码流程如下

  1. 父进程分叉子进程
  2. child 关闭所有继承的文件描述符,stdin、stdout、stderr 除外
  3. child 运行 setgid 和 setuid 以不再以 root 身份运行
  4. 应运行的 Execv 二进制文件

如果我只使用 posix_spawn() 替换上述 4 个步骤,我的程序永远不会崩溃。这似乎验证了我的假设,即我当前的 glibc 在 fork/execv 中存在错误。

将步骤 1-4 替换为 posix_spawn() 的问题在于,它没有为我提供完成步骤 2 和 3 的机制,这对于资源管理和安全性极为重要。是否有任何替代解决方案或我没有考虑过的东西以使稳定版本正常工作?

【问题讨论】:

    标签: fork posix glibc spawn execv


    【解决方案1】:

    如果我只使用 posix_spawn() 替换上述 4 个步骤,我的程序永远不会崩溃。这似乎验证了我的假设,即我当前的 glibc 在 fork/execv 中存在错误。

    glibc 2.13 在posix_spawn 的实现中使用了forkexecve。这可能是您的代码中的另一个错误。仅在 glibc 2.24 及更高版本中,posix_spawn 默认避免使用 fork(这意味着根本不运行 fork 处理程序,这些可能是崩溃或挂起的根源)。

    将步骤 1-4 替换为 posix_spawn() 的问题在于,它没有为我提供完成步骤 2 和 3 的机制,这对于资源管理和安全性极为重要。有没有替代方案

    这样做的唯一方法是引入一个包装程序,它关闭所有文件描述符,切换 ID,然后启动实际的目标程序。

    【讨论】:

      猜你喜欢
      • 2010-12-02
      • 2017-02-15
      • 1970-01-01
      • 2014-08-23
      • 2017-02-03
      • 1970-01-01
      • 1970-01-01
      • 2017-01-22
      • 2016-04-24
      相关资源
      最近更新 更多