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: <20080318125445.GS8368@mit.edu>
Date:	Tue, 18 Mar 2008 08:54:45 -0400
From:	Theodore Tso <tytso@....EDU>
To:	Michael Tokarev <mjt@....msk.ru>
Cc:	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 10:24:03AM +0300, Michael Tokarev wrote:
> Without digging into implementation details (in this case it's
> the fact that /dev/stdin in linux is implemented using a symlink
> to - f.e. - /dev/tty/0 etc), I expect /dev/stdin to always work
> as far as filedescriptor 0 is open, regardless of any permissions
> on the actual tty (if it's a tty in the first place, which is
> not necessary the case) -- exactly the same as /dev/tty works.

Actually, /dev/stdin is not a symlink to the tty.  It's a symlink to
/proc/self/fd/0:

% ls -lL /dev/stdin
0 crw--w---- 1 tytso tty 136, 1 2008-03-18 08:30 /dev/stdin

The problem is that /proc/self/fd/0 is a symlink open file in
question, and so *it* is a symlink to /dev/pts/0.

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

and four years later:

http://www.ussg.iu.edu/hypermail/linux/kernel/0002.3/1022.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0002.3/1250.html

I don't see a mention of it in 2004, so I guess that broke the 4 year
cycle, but here it is once again in 2008.  :-)

       	   	      	   	    	   - Ted
--
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/