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
7
  • @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, 2016 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, 2016 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, 2016 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, 2016 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, 2016 at 11:42

1 Answer 1

Reset to default
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
1
  • 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, 2016 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.