RE: /proc/self/fd/0

Michael Beach (mbeach@awa.com.au)
Tue, 24 Sep 1996 14:36:08 +-1000


I struck a similar problem myself, when going from 1.2.13 to 2.0.17. I have been able to live with the problem, so have not done too much about it.

As far as I have been able to determine (if I am wrong, I would be glad to be given the real facts by someone who knows), somewhere in the 1.3.x series of development kernels, semantics for the /proc/self/fd stuff changed from the so-called Plan9 semantics to something else. As it stands in 2.0.x, I think the stuff in /proc/self/fd appear to be symbolic links. When you read them (eg with an ls -l) you get a textual representation of the device and inode that correspond to that file descriptor, and when you open them, it's just like a normal open of the file corresponding to that device and inode. Under the old (Plan9 ?) semantics, opening them did not attempt to do an open on the inode all over again, it just dup()ed the file descriptor.

In your case, if stdin to your filter was a pipe, I can see the old semantics working as you would expect, as you would just be dup()ing the fd for the pipe, but since the new way likes to look up inodes and such, it starts to sound a bit unhealthy...

My problem was slightly different. I had a program running as root which opened a file that was only readable by root, then passed it to a child program that did not run with root permissions by giving it a /proc/self/fd file as an argument. With the old semantics, it worked, as when the child opens the /proc/self/fd file, it just dup()s an fd and all is sweet. With the new semantics, it tries to open the file again using the device number and inode and dies, because of the permissions on the file. Bummer.

In short, the old way seemed to work a lot like /dev/fd on other Unices, and looked to me like a Good Thing (TM), the new way.... well.... I just can't see what it is useful for, other than as a source of info for fuser(1).

Kernel gurus, please, why did it change?

Regards
M.Beach

----------
From: Allen D. Harpham[SMTP:aharpham@cnweb.com]
Sent: Tuesday, 24 September 1996 3:01
To: linux-kernel@vger.rutgers.edu
Subject: RE: /proc/self/fd/0

Hi all,

I have a printer filter that worked under kernel 1.2.13 that is broke
under 2.04. It looks like the following:

#!/bin/sh
ln -s /proc/self/fd/0 /tmp/$$.html
/usr/bin/html2ascii/html-to-ascii.pl /tmp/$$.html|pr
rm /tmp/$$.html

The port errs file says that the temporary file could not be open (ie.
/tmp/5022.html) . I looked in the Changes documentation, but I could not
find anything in the proc area that could be related.

I have upgraded to the latest version of perl and I am running
libc-5.2.18.

Any ideas?

TIA, Allen
____________________________________________________________________________
Allen D. Harpham, President | Voice: (402)462-4619
Computer Consultants of | Fax: (402)462-4670
Hastings, Inc. | E-mail: aharpham@cnweb.com
1126 N. Briggs Ave. | HTTP: http://www.cnweb.com
Hastings, NE 68901-3713 | ____________________________________________
| Custom programming, Network
| Design and Installation,
| Telecommunications Consulting,
| Web Hosting Services
____________________________________________________________________________