[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Defualt socket server overriding

From: Neal H. Walfield
Subject: Re: Defualt socket server overriding
Date: Wed, 20 Jun 2007 16:20:00 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

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

                            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.

  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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]