Re: Defualt socket server overriding

[Neal H. Walfield]

At Tue, 19 Jun 2007 20:26:05 -0700,
Thomas Bushnell BSG wrote:
> > On 6/20/07, Neal H. Walfield <neal@walfield.org> wrote: 
> >  
> >         > (1) Add a set of new environment variables, e.g.
> >         PFINETSERVER for the pf_inet server and PFLOCALSERVER for the
> >         pf_local server. 
> >         
> >         We should have consistent naming between node names and
> >         environment variables.  The default node names
> >         are /servers/socket/{2,pfinet}, etc.  Perhaps have
> >         SERVERS_SOCKET_PFINET be the name of the environment variable
> >         to use.
> 
> I wonder how you plan to implement this.  The library does not use 
> the #define symbol in practice; it uses /servers/socket/%d and fills in
> %d from the first argument to the socket() call.

Good point.

> It seems to me that an implementation which makes assumptions about how
> people construct names in /servers is unreliable.

These things are part of the system API, so I don't think it is so
unreliable.  I think this is essentially what Roland says in this
message:

                            The io port allocation interfaces have to be
  used on a well-known port location like /servers/ioperm because the name
  goes into libc's implementation of the ioperm function.  It doesn't hurt
  for that to be a symlink to some other /servers or /dev node if there is a
  single server doing several things.  The important point is that what nodes
  to use as the public interface for a system-wide facility is an interface
  choice, and how many different servers actually control which interface
  nodes is an implementation and policy choice.

  http://www.mail-archive.com/bug-hurd@gnu.org/msg14330.html
  13 May 2007

> What about a different strategy, one more "hurdish"?  For example, run
> the program in a pseudo-chroot which overrides the behavior of nodes
> inside /servers?

What is a pseudo-chroot?

I think what you are proposing is essentially filtering the global
name space via some fancy translator.  When we are just interested in
overriding a small parts of the environment and the rest represents a
reasonable default, this may be fine.  Such an approach is, however,
completely contrary to POLP.  I think the right direction is private
name spaces, which can be achieved by passing capabilities.  That was
the other part of my suggestion.

Neal