/dev/fd semantics

From: Bill Rugolsky Jr. (rugolsky@ead.dsa.com)
Date: Mon Feb 28 2000 - 16:12:58 EST


A long time ago ... Fri, 13 Oct 1995 15:18:02 +0200, Linus Torvalds said:
> I just made Linux-1.3.34 (aka "Not quite the buggiest kernel ever")
> available on the normal ftp-sites.

<snip>

> /proc/<pid>/fd/<x> works again. PLAN9 semantics are gone, as those no
> longer work.

<snip>

Here "PLAN9 semantics" means that the following are equivalent:
    fd = open("/dev/fd/n",mode);
    fd = dup(n);
the point being that permissions are not checked on the open, and
the two descriptors share the same file pointer.

In Linux we have /dev/fd -> /proc/self/fd/, but the semantics are
very different: permissions are checked, and the file pointers are
different.

The permissions are a problem whenever a process changes its uid, since the file
permissions seem not to change with it. If we attempt to do something like
the following:

$ ssh -x -q localhost gawk "'BEGIN{print \"Hello, World\" > \"/dev/stderr\"}'"
gawk: cmd. line:1: fatal: can't redirect to `/dev/stderr' (Permission denied)

  or

# su -l rugolsky -c "gawk 'BEGIN{print \"Hello, World.\" > \"/dev/stderr\" }'" 2>&1 | tee /tmp/gawk.out
gawk: cmd. line:1: fatal: can't redirect to `/dev/stderr' (Permission denied)

we run into difficulties.

[ These are contrived examples distilled from actual code. ]

Because /proc/self is a symbolic link to a globally visible /proc/<pid>,
we can't simply loosen the permissions on /proc/self/fd -- doing so would
open enormous security holes.

If we allocate a pty, the permissions are handled by the devpts filesystem:

$ ssh -x -q -t localhost gawk "'BEGIN{print \"Hello, World\" > \"/dev/stderr\"}'"
Hello, World
$ ssh -x -q -t localhost 'ls -l /proc/$$/fd/2'
lrwx------ 1 rugolsky ead 64 Feb 28 14:24 /proc/23428/fd/2 -> /dev/pts/5

Other unix-like systems, like Solaris, implements /dev/fd/<n> as a character device:

   crw-rw-rw- 1 root root 160, 0 Feb 28 15:29 0
   crw-rw-rw- 1 root root 160, 1 Feb 28 15:29 1

The minor number is the file-descriptor to dup(2). This implementation
generally limits the largest fd to 255, but is usually more than adequate for its
intended use.

Now that devfs is in the kernel, is it simple to restore the desired semantics,
while at the same time avoiding the 255 limit? There are two issues:

        1. permissions on the file.
        2. dup() semantics (i.e., single file pointer)

Regards,

   Bill Rugolsky
   rugolsky@ead.dsa.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:21 EST