Kerberos wrapper

[Roland C. Dowdeswell]

On Wed, Dec 05, 2012 at 05:57:44PM +0100, Oliver Loch wrote:
>

> Both look interesting, but they can't be started from inetd - can they?

knc can certainly be started from inetd (or lnetd).  I think that remctl
can as well.

> If one uses KNC, one needs to write a wrapper around it that it
> is started again when it exits?

No, this is not necessary.  KNC can operate in a number of different
modes, though, each of which is a little different.  You can run
the server from inetd as a standard nowait service.  This is how
most people think of inetd services.  You can also run knc as a
standalone server in which case it will fork to process each request
as many daemons do.  You can also run knc as an inetd-style wait
service which means that the listening socket will be handled to
knc and it will serially accept(2) and process connexions.  In this
mode, knc will only serve a single connexion at a time.  But, to
gain concurrency in this mode, you can use prefork which is a small
program that I wrote which will runs as an inetd-style wait service
and will manage a pool of inetd-style wait services.

When a knc server accepts a connexion, it can either fork/exec a
command or make a connexion to a UNIX domain socket and send/receive
the plaintext from the resulting fd.  You can use this method to
run efficient local services that are preforked, threaded or event
driven by simply having them open a UNIX domain socket (and process
the header than knc will write before processing the connexion)
rather than binding to an inet or inet6 address.  lnetd (also
available at the same place) can be used to run inetd-style (wait
or nowait) services on UNIX domain sockets for systems where inetd
doesn't allow UNIX domain sockets.

The combination of knc, prefork, and lnetd allows you to write
relatively efficient preforked kerberised services with ease in
(what I hope) is pretty obvious ways by using the programs as
building blocks for setting it all up.  Each program is designed
to do exactly one thing and (hopefully) do it both simply and well.

I am also intermittantly working on a library to support the very
basic protocol that knc uses to allow people to have the option of
directly linking programs against it for the cases where the above
mentioned tools are deemed to be inadequate.  The library exists
in the git repository but I have set it to not build by default
because I am not yet willing to commit to supporting the API
presented.  This will mature in the coming months.

Documentation for knc, prefork, lnetd as well as a couple of other
tools on which I am working can be found at:

	http://oskt.secure-endpoints.com/

If you have questions about their use, feature suggestions or bug
reports, please feel free to contact me on this e-mail address.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/