prctl(pr_set_dumpable, 1) 有明显的副作用吗？

Question

我在

prctl(pr_set_dumpable, 1)

调用之后使用了

setuid()

来启用核心转储生成。 我发现使用

prctl(pr_set_dumpable, 1)

还会更改

/proc/(pid)

位置处所有文件的所有者：组，这是副作用还是预期的？

Answer 1

郑重声明，我自己在试图关闭核心转储时被这个绊倒了，而且我没有使用setuid

。当我运行这个程序时：

#include <stdio.h>
#include <stdlib.h>
#include <sys/prctl.h>
#include <unistd.h>

int main(int argc, char *argv[]) {
  char ls_cmd[64];
  snprintf(ls_cmd, sizeof(ls_cmd), "/bin/ls -ld /proc/%d/fd", getpid());

  system(ls_cmd);

  if (0 > prctl(PR_SET_DUMPABLE, 0)) {
    perror("can't prctl(PR_SET_DUMPABLE)");
    return 1;
  }

  system(ls_cmd);

  return 0;
}

我得到了这个结果（已编辑）：

$ ./prctl-and-proc
dr-x------ 2 myuname mygroup 0 Feb  2 17:08 /proc/23999/fd
dr-x------ 2 root root 0 Feb  2 17:08 /proc/23999/fd

Answer 2

是的，它是通过 dumpable 完成的。您可以通过查看来了解原因

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/fs/proc/base.c?id=refs/tags/v3.14

并搜索“可转储”。 inode uid 首先设置为 GLOBAL_ROOT_UID，然后仅在任务可转储时设置为所有者 uid。

Answer 3

您确定是

prctl

 而不是 

setuid

 系统调用改变了 

/proc/self/

 的所有权吗？我猜

setuid

应该改变它......

Answer 4

人进程 将“dumpable”属性重置为 1 会将 /proc/[pid]/* 文件的所有权恢复为进程的真实 UID 和真实 GID。