the standard way of passing file descriptors is by fork/exec. this allows security is handled by the normal means.
Where FD passing is useful is to avoid that fork/exec overhead. The apps I was working on had a relatively simple front-end process that would field requests that required data to be crunched in various ways. Some of this crunching had *very* high overhead relative to the volume of requests coming in. Fork/exec simply would not scale. Instead we wrote long-lived backend processors, and let the front-end act as a connection multiplexor, handing the FDs from the incoming requests around as required to crunch the data. This significantly reduced the system-related overhead, and also made it very easy to chain filters together with the front-end managing the whole thing from a single configuration file.
this case would be handled by fork/exec. the general case is handled by srv(3).
Well, srv(3) in reverse ... sort of. I've been thinking about doing something like this for a while now, specifically for httpd. What I've been scratching my head over is if the handoff between httpd and the backends should be a raw file descriptor, or a 9P interface. I need to scratch together a prototype to experiment with but there's too much on my plate right now.
--lyndon