5

On CentOS 7, I am trying to debug an issue where the nginx amplify agent cannot read /proc/$pid/io even though it is owned by the proper user.

One of the nginx worker processes right now is pid 5693:

# ps aux | grep 5693
nginx     5693  0.5  0.0 129000 14120 ?        S    Jul18  16:10 nginx: worker process

the nginx user has permission to read the file:

# ls -lAh /proc/5693/io
-r-------- 1 nginx nginx 0 Jul 20 11:30 /proc/5693/io

...but can't actually read it:

# sudo -u nginx /bin/sh -c 'cat /proc/5693/io'
cat: /proc/5693/io: Permission denied

...even though selinux is disabled:

# sestatus
SELinux status:                 disabled

Root is able to read /proc/5693/io just fine, and the nginx user can read other files in /proc/5693. It seems like there must be some other security mechanism in place that is preventing the access, but I have no idea what it might be.

|improve this question
  • @RuiFRibeiro no mention of /proc in fstab at all. mount shows: proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) – Jay Paroline Jul 20 '16 at 20:29
  • 2
    According to what proc(5) has to say on /proc/[pid]/io, "Permission to access this file is governed by a ptrace access mode TRACE_MODE_READ_FSCREDS check; see ptrace(2)." The Ptrace access mode checking section of the ptrace(2) man page contains a list of things that are checked to grant or deny permission, including wether the process is marked dumpable, wether you have the same fsuid as the target process etc, might be worth it having a look at it. – user60039 Jul 25 '16 at 0:31
  • @user60039 ptrace(2) only seems to mention yama for permissions unless I'm looking at the wrong thing. /proc/sys/kernel/yama doesn't exist on this system and systemctl -a | grep yama doesn't return anything so as far as I can tell we don't have yama. – Jay Paroline Jul 26 '16 at 20:34
  • The documentation was added very recently, check upstream. lwn.net/Articles/692203 man7.org/linux/man-pages/man5/proc.5.html At a first guess you need to change GID as well as UID. – sourcejedi Aug 30 '16 at 7:16
  • The distribution tags are only useful when the question is specific to a given distribution. As far as I can tell, your problem could occur on any distro and is more about how the permissions on your system are working. I therefore removed both distro tags. Feel free to ping me in /dev/chat if you want to discuss this. – terdon♦ Sep 7 '16 at 11:42
2

According to what proc(5) has to say on /proc/[pid]/io, _"Permission to access this file is governed by a ptrace access mode TRACE_MODE_READ_FSCREDS check; see ptrace(2)."_ The Ptrace access mode checking section of the ptrace(2) man page contains a list of things that are checked to grant or deny permission, including whether the process is marked dumpable, whether you have the same fsuid as the target process etc, might be worth it having a look at it.

The documentation was added very recently, check upstream.

I suspect you need to change the GID your process is running under, in addition to the UID.

|improve this answer
  • I think this solves it. sudo -u nginx -g nginx /bin/sh -c 'cat /proc/24454/io' works, so I will relay this info to the nginx guys – Jay Paroline Sep 7 '16 at 21:19

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.