I'm using hidepid=2 to mount /proc, so users can't see any but their own processes. A particular binary I want to use has been restricted to rwx–x–x permissions, so only its owner (root) can read it but other users can execute it. A normal user can run it without problems, but can't see the process with "ps". If the binary has its permissions changed so the user can read it, then the process appears in "ps" again.
A reproducible example:
sudo mount -o remount,hidepid=2 /proc
sudo cp $(which yes) /tmp
sudo chmod 0711 /tmp/yes
/tmp/yes >/dev/null &
ps aux | grep yes # The process is hidden
sudo ps aux | grep yes # The process can be seen by root
kill %1
sudo chmod og+r /tmp/yes
/tmp/yes >/dev/null &
ps aux | grep yes # The process appears in the list
Why is this happening? It obviously has some relationship to the file permissions, but it shouldn't have: if the process belongs to a user, the user should be able to see it even if the binary is restricted.
My guess is that, as the link "exe" inside /proc/PID points to the binary being executed, the kernel is forbidding all access the the directory in addition to the binary itself. But I'd like to know if this is true or just a consequence of some other thing going on.
Thanks in advance!
Best Answer
The answer is (or at least starts) in
fs/proc/base.c
(unchanged from kernel 3.12 to 4.2 at least)The code above is the starting point for determining if a specific
/proc/PID
entry can been seen to exist or not. Whenhide_pid
is set to 2 it returns-ENOENT
if you don't have the required permission. Permissions are checked via:has_pid_permissions()
→ptrace_may_access()
→__ptrace_may_access()
__ptrace_may_access()
denies access because the process is not "dumpable" as it was created from an unreadable executable image, as determined during process creation:setup_new_exec()
→would_dump()