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]

Date:	Sun, 23 Mar 2008 05:35:39 +0100
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	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 Tuesday 18 March 2008 15:32, Al Viro wrote:
> 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.

/me puts his admin hat on

This issue (that /proc/self/fd/0,1,2 don't always work)
is a real problem. I was bitten by it more than once, thrying to do
something like:

setuidgid http_user httpd --log-to-file /proc/self/fd/2

Doesn't work. Which is sort of stupid - I _already_
have fd 2 open, what's the point in prohibiting me from
opening it again?

(As to why: there are lots of software which insist of logging
either to syslog or the file, whereas I really prefer to log
to stdout/stderr.)

> 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

I am not an expert, so my question might be stupid, but:
can open("/proc/PID/fd/N") be special-cased to always succeed
if PID = current process' PID and fd N is already open?
--
vda
--
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/