On Tue, Dec 23, 2008 at 08:39:27PM -0500, erik quanstrom wrote:
> > /srv is not an ideal answer, though it is the one I feared would be given.
> > /srv allows any process running as a given user to access the posted fd, and
> > does not respect namespace or process group boundaries.  I want a mechanism
> > to pass a file descriptor to one target process so that I can pass an fd
> > across namespaces without giving _all_ namespaces access to said fd.
> > 
> > A /srv that 1) was not enumerable, 2) allowed only single opens, and 3) used
> > secure identifiers (capabilities, similar to devcap) would suffice, as
> > processes could post an fd to recieve an identifier, pass the identifiers to
> > another process, and then turn the identifier into an fd.
> 
> on unix, which is not a distributed system, passing fds around makes
> a certain amount of sense.  in plan 9, i would think that the ideal
> answer would need to allow for the unrelated processes running
> on seperate machine.  i would also think that it would allow the
> standard authentication mechanisms to work.  fds really don't fit
> either one of those criteria.

All of the same comments apply to /srv (though srv^2 is trying to solve
this).

> but we're talking generalities.  what's the specific application?

1) Sending files across namespaces so that I can spawn acme at rio startup
and plumb to it without having to recreate mounts in its namespace.

2) Sending parts of namespaces around locally without needing to run an
exportfs in that namespace.  (i.e. open() a directory && sendfd() that to
another process who can mount() it.)  Among other things, this allows the
shell (and others) to easily offer the current working directory fd (rather
than path) to rio for tab completion.

3) Some small thought about being able to implement srv^2 entirely in
userland, and what the primitives would look like.  sendfd() or the above
outlined devcapsrv seems better than the current devsrv to me, but I confess
I might be mistaken.

Thoughts? 
--nwf;