linux-kernel - Re: RFC: /dev/stdin, symlinks & permissions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080318143222.GF10722@ZenIV.linux.org.uk>
Date:	Tue, 18 Mar 2008 14:32:22 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Theodore Tso <tytso@....edu>, Michael Tokarev <mjt@....msk.ru>,
	Andreas Schwab <schwab@...e.de>,
	Linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: 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:
> 
> http://www.ussg.iu.edu/hypermail/linux/kernel/9609.2/0371.html

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.

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