Status of innbind and Solaris

[Bill Davidsen]

Russ Allbery wrote:
> I didn't quite get this finished tonight, but I'm close.  A bit more work
> on it tomorrow should finish it off.
> 
> The problem, as those who have tried to run CURRENT on Solaris know, is
> that the neat hack of creating a socket and then running a setuid root
> helper program to bind the socket only works on operating systems that
> actually implement native Berkeley sockets.  On streams-based systems like
> Solaris, somehow the privileges of the creator of the socket attach to it,
> rather than the privileges of the person running bind, and the sub-process
> can't bind even though it has an effective UID of root.
> 
> This means there's no choice but the old-style inndstart wrapper on those
> operating systems.

Which is simple, portable, well-tested, etc. The effort you are putting 
into getting innbind to work seems to indicate that it will always need 
to know a lot more about the host o/s than inndstart. And if you do 
nnrpd as a daemon you have to resolve the problem there as well.

I admit I like simplicity, I'd be happy with inndstart starting innd and 
optionally nnrpd daemon, and having not a single ifdef needed. Just my 
preference, but I looked at socket passing for something else and 
decided it was complex and on AIX (at that time) didn't work.

> 
> This is a lot more complex, though, and I really don't want to resurrect
> inndstart.  I also want something relatively generic that can also be used
> for nnrpd.  Thankfully, only long-running daemons have to bind in this
> fashion, which means it doesn't have to be blazingly fast.
> 
> The plan is therefore to keep innbind as-is for those operating systems
> that support it.  Linux, *BSD, and the like will continue to get the nice,
> new semantics.  The only change is that innbind will have two other modes:
> 
>     innbind -t 119
>     innbind -e 0,2,0.0.0.0,119 -- /news/bin/innd
> 
> The first will try using innbind the way that it's meant to be used to
> bind something to port 119.  If this works, innd will proceed as normal.
> It will just always run this during startup to check to see if it has to
> do something complicated.
> 
> The second is something complicated.  Run with -e, innbind will walk
> through its arguments as before but will also do the socket creation as
> well as the bind.  It will stop when it gets to -- and then take
> everything after that as a command to run.  It will add -p <fdss> to the
> beginning of the argument list (where <fdss> is a comma-separated list of
> open, bound file descriptors) and then exec the command it was given.
> 
> So innd will first see if its port is >= 1024 or if it's already running
> as root, and if so, will just continue as normal.  Otherwise, it will run
> innbind -t on its port.  If that succeeds, it will continue as normal.
> 
> If that fails, it will build a list of all of the addresses it wants to
> listen to, and then exec innbind -e in the above manner, passing it innd's
> original argument list.  Then, the second time around, it will see the -p
> option, skip all of the network setup, and just use those file descriptors
> as is.
> 
> The flow of this in the Solaris case is more complex than the original
> inndstart solution, but everything is much simpler for Linux.  For
> Solaris, it's still significantly nicer than what we had before, because
> inndstart isn't necessary, you don't have to remember to run it instead of
> innd, and we don't need the code for it in places like ctlinnd xexec.
> 
> innd will be far easier to debug on Linux, where the tricks of before
> won't be necessary.  On Solaris, you'll still have to replace innd with a
> wrapper or the like to get good debugging information, or start it
> manually with innbind.
> 
> Comments?
> 


-- 
    -bill davidsen (davidsen at tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me