In a program I'm enumerating network namespaces by scanning /proc/pid/ for ns/net (sym) links. This program runs inside the "root" namespaces (original init) of the host itself. Normally, I need to run the scanner part as root, as otherwise I will have only limited access to other processes' /proc/pid/ information. I would like to avoid running the scanner as root if possible, and I would like to avoid the hassle of dropping privileges.

Which Linux capability do I need to set for my scanner program so it can be run by non-root users and still see the complete /proc/pid/ tree and read network namespace links?


After some trial and error, I found out that in fact CAP_SYS_PTRACE is needed.

In contrast, CAP_DAC_READ_SEARCH and CAP_DAC_OVERRIDE don't give the required access, which includes readlink() and similar operations.

What I'm seeing can be cross-checked: first, ptrace.c gives the necessary clue in __ptrace_may_access():

/* May we inspect the given task?
 * This check is used both for attaching with ptrace
 * and for allowing access to sensitive information in /proc.
 * ptrace_attach denies several cases that /proc allows
 * because setting up the necessary parent/child relationship
 * or halting the specified task is impossible.

And second, the nsfs-related functions, such as proc_ns_readlink() (indirectly) call __ptrace_may_access().

And finally, man 7 namespaces mentions:

The symbolic links in this subdirectory are as follows: [...] Permission to dereference or read (readlink(2)) these symbolic links is governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see ptrace(2).

  • CAP_SYS_PTRACE is God-like; you can control any process and make it do anything; a rationale on why it should be preferred to just root would be great. Unless the purpose is to hide the capabilities from dumb sysadmins using dumb tools like top or ps ;-) – mosvy Jan 9 '20 at 23:14
  • root/uid0 has CAP_SYS_PTRACE, as well as all other capabilities. Thus, this is not about sysadmins, but reduction of which means are available if a process or binary gets compromised. Whether the reduction is sufficient is open for debate, but that's one purpose of my quest to get better insights into "is it worth it?". Yet, having ptrace but no file system caps might still raise the bar for many an attacker considerably. – TheDiveO Jan 10 '20 at 7:34
  • This probably serves as a good example that capabilities on their own are only going so far and need to be accompanied by apparmor or other MAC-like syscall guardian. However, the jury is still out whether the effort and risks benefit the outcome, at least at this time. – TheDiveO Jan 10 '20 at 9:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.