Status of innbind and Solaris
rra at stanford.edu
Fri May 21 21:56:55 UTC 2004
Bill Davidsen <davidsen at tmr.com> writes:
> Russ Allbery wrote:
>> This means there's no choice but the old-style inndstart wrapper on
>> those operating systems.
> Which is simple, portable, well-tested, etc.
And the second largest source of confusion about a new INN installation
after the history database, although I suppose some of that could be
obviated by adding a check to make sure it's setuid to rc.news (although
that's difficult to do portably in shell).
The biggest problem with inndstart, though, is that it has to do way too
much and it does it as root. inndstart sucks in the entire inn.conf
parsing infrastructure, and while I've tried to test this as thoroughly as
I can, I am very much not comfortable with using it in a setuid root
program. Just being well-tested doesn't mean that something doesn't have
unfound security vulnerabilities.
It also constantly hampers debugging, requires complicated workarounds to
let you strace innd, and was frankly rather hideous when you needed IPv6
support. I just find it in general more difficult to support.
> 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.
This is true. I don't think it has to know that much more (it just has to
know whether or not binding an inherited file descriptor works, and if
not, how to pass a file descriptor back to its parent), but it does use
more deep Unix tricks than inndstart did.
> And if you do nnrpd as a daemon you have to resolve the problem there as
Well, no, I don't. That's actually the whole point. All of the code to
call innbind is in libinn and is completely encapsulated. A program that
wants to bind to a socket just calls network_bind_ipv4, network_bind_ipv6,
or network_bind_all as appropriate and then uses the resulting file
descriptor. That's it. nnrpd will work exactly the same way as innd
(which has historically been a huge problem for nnrpd in daemon mode;
right now, you have to run it as root and then it has to drop privileges).
Also, all this code is now done and tested and I know it works on Linux,
*BSDs, and Solaris, and I have a fairly high degree of confidence that it
works on HP-UX and IRIX (although I haven't ran the tests there yet, just
due to lack of time). But most platforms except Linux and the *BSDs are
SVR4-based and supports STREAMS, which means that the file descriptor
passing works cleanly, and I think that the number of platforms that don't
support just binding in the child is small.
> I admit I like simplicity, I'd be happy with inndstart starting innd and
> optionally nnrpd daemon, and having not a single ifdef needed.
I like simplicity too. That's why I did all of this work. I want to be
able to just run innd and not think about weird wrappers. :)
> 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.
It does indeed not work on AIX (pipes are not streams on AIX), but it
doesn't have to since AIX supports binding in the child. :)
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
More information about the inn-workers