Most of the reactions I got on my /proc/<pid>/fd/<fd> idea pointed out
security leaks. I must admit that, in the true spirit of Unix *grin*
security was not the first issue that I considered. Even the
considerations below are certainly not enough to make it secure.

If I had lots more time (say, no full time job) I might have been
tempted to try to implement this, but you know how it goes...

I quote a "random" message:
> The security implications of this are, umm, interesting.
> 
> /proc/<pid>/fd should certainly be mode 700 to prevent spying on other
> user's processes.

Perhaps (if you want users to be able to see *what* fds are in use by
another process, the /proc/<pid>/fd directory may be readable, but at
least all the fds in it should be mode 700 owned by the process' uid.
(what would be possible if the directory is writable for someone and
you allow file system ops like rename on fds boggles the mind)

> The correct behavior in the presence of setuid would be hard to work
> out since some of the fd's might only have been accessible under the
> original permissions while others are accessible only under the new
> permissions..

I would suppose that for setuid programs, that /proc/<pid>/fd should
be mode 700 and owned by root, independent of the real and effective
uid of the process. This would also hide which fds are open by such
a process.

Another one:
> > But one of the things I've always wanted to do to was to change the
> > object some fd refers to after the fact. For instance, if I started
> > some command 'verbose_command &' and I forgot the redirection. To be
> > able to change its stdout to some file would be very nice.
> 
> Yes, it would.  Unfortunately, it opens up a 55-gallon drum full of worms.
> If the program has done a stat() to find out if its standard output is a
> teletype, what happens if you throw its output stream into a disk file?

Possibly; I'm not entirely convinced though. There are of course
programs that need to be very aware of the type of file they are
dealing with. Kermit, to name one. If you are stupid enough to replace
its communication line with a disk file, you surely deserve what you
get. On the other hand, there are programs that simply try to be too
smart for their purpose. I would almost say that ls is one of those: it
can be argued that it need not detect if it should do multi-column
output or not. If you want it, specify a flag, or pipe it though mc (am
I showing a v7-ism here, or even worse, a v7-ism local to Nijmegen?). I
certainly don't mind "breaking" such progams, since they are really
broken already.

-Olaf.
--
___ Olaf 'Rhialto' Seibert                                 rhialto@mbfys.kun.nl
\X/ An original idea. That can't be too hard. The library must be full of them.

------------------------------------------------------------------------------