1

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.

Note: not sure if this is allowed but I am crossposting this question from U&L as it's not getting attention there and is affecting our production server. The original question is here: https://unix.stackexchange.com/questions/297190/owner-cant-read-proc-pid-io - I would just migrate it but do not see a way to do that.

Community
  • 1
Jay Paroline
  • 159
  • 1
  • 9

2 Answers2

1

The amplify agent process may need to be granted PTRACE. This looks somewhat unusual and is probably best taken up with the nginx folks, but you can try looking at man 8 setcap to see how to grant PTRACE to whatever the amplify program is.

Jonah Benton
  • 1,252
  • 7
  • 13
1

Answered here: https://unix.stackexchange.com/questions/297190/owner-cant-read-proc-pid-io

The issue seems to be the GID needs to be set in addition to uid.

Community
  • 1
Jay Paroline
  • 159
  • 1
  • 9