This has the potential to be a large security hole.  Obviously at least
uid matching validation would apply but this still isn't perfect.

I can think of cases where processes, esp. setuid processes, assume their
fds are "secure".  There are many cases where you have a binary running
as setuid root that toggles back and forth from root and a normal user.

As a normal user you could gain access to an fd for input into a process
that will then later use that input to do things.  In essence it lets you
bypass the file permissions by "stealing" the fd.  Under normal conditions 
you are safe because of permissions and/or specific checks done by the program
at hand.

Some things that come to mind are sendmail, rlogin and rshd (when doing
the ruserok()).

I'm not sure how these run on NetBSD, but rlogin and rshd on Sun's run
ruserok() as the user in some conditions.

Also, many programs use pipes as a way to securely pass secure or confidential
data between them (some license manager's use this scheme...).

I like the idea though, but I don't see a way to make it secure.  Granted
you can make a process scribble on a fd or read in data and do anything else
using ptrace() and it's ilk, but that at least requires you to really be
the user or root and it raises the stakes in terms of difficulty.

-Mark

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