Re: 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/

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos wrapper

[Nico Williams]

On Dec 5, 2012 11:00 AM, "Oliver Loch"  wrote:
>
> Both look interesting, but they can't be started from inetd - can they?
>
> If one uses KNC, one needs to write a wrapper around it that it is
started again when it exits?

KNC most certainly can be launched from inetd, and indeed that's the most
common use of it.  Also, there's a couple of helpers in Roland's github
account (http://github.com/elric1) for a) pre-forking a pool of knc
processes ("prefork"), b) an equivalent of inetd for Unix domain sockets
("lnetd"), which can be put together to builds high performance kerberized
services quite easily.

Nico
--

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos wrapper

[Russ Allbery]

Oliver Loch  writes:

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

remctld can run from inetd or standalone, however you would prefer.

-- 
Russ Allbery (r...@stanford.edu) 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos wrapper

[Oliver Loch]

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

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

KR,

Oliver

Am 03.12.2012 um 19:37 schrieb Booker Bense :

> Remctl is also a great solution to the "kerberized" inetd problem. 
> 
> http://www.eyrie.org/~eagle/software/remctl/
> 
> 
> On Sat, Dec 1, 2012 at 2:40 PM, Oliver Loch  wrote:
> Hello,
> 
> while playing around with some ideas on sending notifies from/to a machine, I 
> started playing with inetd and ended up missing a Kerberos wrapper.
> 
> I'm not even sure if it can be done with Kerberos, but the idea is to have a 
> tool similar to "stunnel" ( https://www.stunnel.org/index.html ), that can be 
> "intercepted" into the data stream between the executed command of inetd and 
> the client on the other end. Besides providing authentication (and 
> authorization), it could also provide encryption, like Kerberos/GSSAPI does 
> in some OpenLDAP scenarios.
> 
> KR,
> 
> Oliver
> 
> 
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos wrapper

[Booker Bense]

Remctl is also a great solution to the "kerberized" inetd problem.

http://www.eyrie.org/~eagle/software/remctl/


On Sat, Dec 1, 2012 at 2:40 PM, Oliver Loch  wrote:

> Hello,
>
> while playing around with some ideas on sending notifies from/to a
> machine, I started playing with inetd and ended up missing a Kerberos
> wrapper.
>
> I'm not even sure if it can be done with Kerberos, but the idea is to have
> a tool similar to "stunnel" ( https://www.stunnel.org/index.html ), that
> can be "intercepted" into the data stream between the executed command of
> inetd and the client on the other end. Besides providing authentication
> (and authorization), it could also provide encryption, like Kerberos/GSSAPI
> does in some OpenLDAP scenarios.
>
> KR,
>
> Oliver
>
>
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos wrapper

[Nico Williams]

See http://github.com/elric1/knc .

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos wrapper

[Oliver Loch]

Hello,

while playing around with some ideas on sending notifies from/to a machine, I 
started playing with inetd and ended up missing a Kerberos wrapper.

I'm not even sure if it can be done with Kerberos, but the idea is to have a 
tool similar to "stunnel" ( https://www.stunnel.org/index.html ), that can be 
"intercepted" into the data stream between the executed command of inetd and 
the client on the other end. Besides providing authentication (and 
authorization), it could also provide encryption, like Kerberos/GSSAPI does in 
some OpenLDAP scenarios. 

KR,

Oliver


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos