Messages in this thread | | | Date | Tue, 18 Mar 2008 08:54:45 -0400 | From | Theodore Tso <> | 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
| |