lkml.org 
[lkml]   [2013]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: /proc/pid/fd && anon_inode_fops
    On Sun, Aug 25, 2013 at 06:23:17AM +0100, Al Viro wrote:
    > On Sat, Aug 24, 2013 at 11:24:32PM +0200, Willy Tarreau wrote:
    >
    > > I doubt it. It seems to me that most such entries are implemented
    > > for completeness while most valid uses only concern /proc/self/fd.
    > > Maybe if we had an option so that only /proc/self/fd would actually
    > > allow to access the fds while all /proc/pid/fd would only show what
    > > they map to, it would be a good step forward.
    >
    > How? The fundamental problem is not visibility of that stuff, it's
    > new opened file for the same object (Linux behaviour) vs. new descriptor
    > refering to the same opened file (*BSD and friends). We can't get
    > anon_... sanely reopened in the former semantics and they are very
    > visibly different for regular files, so switching to *BSD one is not
    > feasible - too high odds of userland breakage. The difference in
    > semantics, of course, is that on Linux opening /dev/stdin gives you
    > a descriptor with independent current IO position; on *BSD you get
    > a descriptor sharing the current IO position with stdin. IOW, it's
    > independent open() of the same file vs. dup().
    >
    > We are really stuck with the current semantics here - switching to
    > *BSD one would not only mean serious surgery on descriptor handling
    > (it's one of the wartier areas in *BSD VFS, in large part because
    > of magic-open-really-a-dup kludges they have to do), it would change
    > a long-standing userland API that had been there for nearly 20 years
    > _and_ one that tends to be used in corner cases of hell knows how many
    > scripts.

    Thanks for explaining Al, that really helps me understand. However
    there's still a difference between /proc/pid called from the process
    itself (=/proc/self) and called from other processes that seems to
    suit the situation :

    willy@eeepc:~$ ls -la /tmp/bash
    -r-x--x--x 1 root users 916852 2013-08-25 08:19 /tmp/bash*
    willy@eeepc:~$ exec /tmp/bash -i
    willy@eeepc:~$ echo $$
    22678
    willy@eeepc:~$ ls -la /proc/22678/fd
    ls: cannot open directory /proc/22678/fd: Permission denied
    willy@eeepc:~$ ls -la /proc/22678/exe
    ls: cannot read symbolic link /proc/22678/exe: Permission denied
    willy@eeepc:~$ cat /proc/22678/fd/0
    cat: /proc/22678/fd/0: Permission denied

    but :
    willy@eeepc:~$ read < /proc/22678/fd/0
    azerazerazer
    willy@eeepc:~$ echo $REPLY
    azerazerazer

    strace clearly shows that the process was allowed to inspect itself
    and the other ones were not :

    willy@eeepc:~$ strace -p 22678
    open("/proc/22678/fd/0", O_RDONLY|O_LARGEFILE) = 3

    willy@eeepc:~$ strace cat /proc/22678/fd/0
    open("/proc/22678/fd/0", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied)

    It looks like this difference was introduced by this patch (which also fixes
    this issue we've been having for a very long time on 2.4 and early 2.6) :

    8948e11 Allow access to /proc/$PID/fd after setuid()

    Thus I'm wondering if something like this could help, the idea would be
    that a with the appropriate mount option, a task could only look at its
    own descriptors unless it's running with privileges :

    static int proc_fd_permission(struct inode *inode, int mask,
    struct nameidata *nd)
    {
    if (task_pid(current) == proc_pid(inode))
    return 0;
    if (capable(CAP_DAC_OVERRIDE))
    return 0;
    if (proc_mounted_with_strict_option)
    return -EACCES;
    return generic_permission(inode, mask, NULL);
    }

    Thus it would not change the default behaviour except for people who would
    mount /proc with a special option.

    Thanks,
    Willy



    \
     
     \ /
      Last update: 2013-08-25 09:01    [W:2.240 / U:0.108 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site