(In reply to Christian Horn from comment #0)
>
> - We think /proc/PID/io should have wider permissions, like
>   /proc/$$/{status,mounts,smaps,stat} and other files.
>   We just could not directly come up with a good reason to
>   have /proc/PID/io readable to owner/root only.

Well. The upstream commit 1d1221f375c94ef96 ("proc: restrict
access to /proc/PID/io") says:

    /proc/PID/io may be used for gathering private information.  E.g.  for
    openssh and vsftpd daemons wchars/rchars may be used to learn the
    precise password length.  Restrict it to processes being able to ptrace
    the target process.

    ptrace_may_access() is needed to prevent keeping open file descriptor of
    "io" file, executing setuid binary and gathering io information of the
    setuid'ed process.

This is CVE-2011-2495, btw.

So I think we should close this bug as NOTABUG.

If you think that the patch above was wrong and can be reverted, please
forward your concerns to lkml and/or security.

Closing BZ due to the justification given in comment 1.

-David

This is a very unfortunate situation, and while I can understand the concerns listed in the CVE an inverse security problem is also happening - many people are forced to run performance tools in insecure modes (i.e. as privileged users, incl. daemons running as root) because they need access to this information to solve performance problems.

I wonder if a compromise solution could work, where the permissions could be configurable e.g. via a sysctl setting, to allow sysadmins to choose what is going to work best for individual systems?

Regarding the referenced kernel commit and specifically "Restrict it to processes being able to ptrace the target process." - I experimented with trying to give CAP_SYS_PTRACE to userspace processes, but haven't been able to make it work.  If we can figure this out, perhaps this is an avenue we can explore to provide the sysadmin-opt-in mechanism.  If anyone can see what I've missed here, please let me know ... thanks.

$ sudo setcap cap_sys_ptrace=eip /usr/bin/cat
$ getcap /usr/bin/cat
/usr/bin/cat cap_sys_ptrace=eip
$ 

$ /usr/bin/cat /proc/1/io
/usr/bin/cat: /proc/1/io: Permission denied
$ sudo /usr/bin/cat /proc/1/io
rchar: 594562382077
wchar: 182137796785
syscr: 791652377
syscw: 199627602
read_bytes: 111509180928
write_bytes: 142228922368
cancelled_write_bytes: 6872858624
$ 

$ sudo setcap -r /usr/bin/cat
$ getcap /usr/bin/cat
$ 

Should this work?  I was hopeful based on reading kernel/ptrace.c along with capabilities(7), setcap(8) and cap_from_text(3).

(In reply to Nathan Scott from comment #4)
> 
> $ sudo setcap cap_sys_ptrace=eip /usr/bin/cat
> $ getcap /usr/bin/cat
> /usr/bin/cat cap_sys_ptrace=eip
> $ 
> 
> $ /usr/bin/cat /proc/1/io
> /usr/bin/cat: /proc/1/io: Permission denied

Well, I know absolutely nothing about capabilities ;)

But. Yes you need CAP_SYS_PTRACE, otherwise the ptrace_may_access() check in
do_io_accounting() will fail. However, do_io_accounting() is called by sys_read()
paths, you need to open the file first and open("/proc/1/io", O_RDONLY)
obviously fails.

CAP_DAC_READ_SEARCH=2 + CAP_SYS_PTRACE=19 seems to work:

    # setcap 2,19=eip ./cat

    $ ~root/cat /proc/1/io
    rchar: 88739747832
    wchar: 11804927869
    syscr: 91425808
    syscw: 35006320
    read_bytes: 2993438720
    write_bytes: 6539235328
    cancelled_write_bytes: 537047040

Aha - very helpful, thanks Oleg.