[lkml]   [2008]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC: /dev/stdin, symlinks & permissions
    On Tue, Mar 18, 2008 at 08:54:45AM -0400, Theodore Tso wrote:

    > The main issue is that at the moment, when you open /proc/self/fd/X,
    > what you get is a new struct file, since the inode is opened a second
    > time. That is why you have to go through the access control checks a
    > second time, and why there are issues when you have /dev/stdin
    > pointing to a tty which was owned by user 1, and then when you su to
    > user 2, you get a "permission denied" error.
    > On other operating systems, opening /proc/self/fd/X gives you a
    > duplicate of the file descriptor. That means that the seek pointer is
    > also duplicated. This has been remarked upon before. Linux 1.2 did
    > things "right" (as in, the same as Plan 9 and Solaris), but it was
    > changed in Linux 2.0. Please see:

    The real issue is that it was not Plan 9 semantics to start with.

    See 9/port/devproc.c and 9/port/devdup.c; the former is procfs and
    while it does have <pid>/fd, the sucker is not a directory - it's
    a text file containing (more or less) the pathnames of opened files
    of that process. The latter is an entirely different thing - it's
    a separate filesystem (#d instead of #p, FWIW). There you have
    per-descriptor files to open and yes, that'll give you dup(). What
    you do not have there is per-process part.

    IOW, you can get pathnames of opened files for other processes via
    procfs *AND* you can get open-that-does-only-dup for files in your
    descriptor table - on a separate filesystem.

    1.2 tried to mix both. I'm not actually sure that it was a good idea wrt
    security, while we are at it...

    We could implement Plan 9 style dupfs, but to do that without excessive
    ugliness we'd need to change prototype of ->open() - it must be able to
    return a reference to struct file different from anything it got from
    caller; probably the least painful way would be to make it return
    NULL => success, use struct file passed to ->open()
    ERR_PTR(-err) => error
    pointer to struct file => success, caller should drop the
    reference to struct file it had passed to ->open() and use the return value.
    Still a mind-boggling amount of churn - probably too much to bother with.

    PS: from Plan 9 proc(3) [they use section 3 for kernel filesystems]:
    The read-only fd file lists the open file descriptors of the process.
    The first line of the file is its current directory; subsequent lines
    list, one per line, the open files, giving the decimal file descriptor
    number; whether the file is open for read (r), write, (w), or both (rw);
    the type, device number, and qid of the file; its I/O unit (the amount
    of data that may be transferred on the file as a contiguous piece; see
    iounit(2)), its I/O offset; and its name at the time it was opened.

     \ /
      Last update: 2008-03-19 22:25    [W:0.022 / U:189.160 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site