Re: RFC: /dev/stdin, symlinks & permissions

[Theodore Tso <tytso@MIT.EDU>]

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