I'm certainly no expert, so there could easily be some security issues that
I'm not seeing right now, but...
It seems to me that the CAP_DAC_READ_SEARCH capability ought to allow
readlink() to succeed on a "magic symlink" even when the uid/gid would
otherwise disallow it.
The capabilities(7) man page says:
CAP_DAC_READ_SEARCH
* Bypass file read permission checks and directory read and execute
permission checks;
etc.
This could be handy to see what files a process has open without using
full-blown root priv. E.g., "ls -l /proc/nnnn/fd/" run via setpriv or
capsh.
Thanks for listening,
-Jeff
---------
The following illustrates the current situation. 'rsudo' is a personal script
I use to run a command with dac_read_search; sort of a 'read only' version of
sudo. (I really should clean it up a bit and post it somewhere.)
jeff@ups:~$ ls -l /proc/1/fd/0
ls: cannot access '/proc/1/fd/0': Permission denied
jeff@ups:~$ sudo ls -l /proc/1/fd/0
lrwx------ 1 root root 64 Oct 23 13:48 /proc/1/fd/0 -> /dev/null
jeff@ups:~$ sudo readlink /proc/1/fd/0
/dev/null
jeff@ups:~$ rsudo ls -l /proc/1/fd/0
ls: cannot read symbolic link '/proc/1/fd/0': Permission denied
lrwx------ 1 root root 64 Oct 23 13:48 /proc/1/fd/0
jeff@ups:~$ rsudo readlink /proc/1/fd/0
The first 'rsudo' above ran the cmd:
sudo setpriv --inh-caps +dac_read_search --ambient-caps +dac_read_search
--reuid=1000 --regid=1000 --init-groups -- ls -l /proc/1/fd/0
The second did the same for 'readlink /proc/1/fd/0'
