Jeremy Howard wrote:
>
> Ken Murchison wrote:
> > Jeremy Howard wrote:
> > >
> > > Ken Murchison wrote:
> > > > Now that I think about it, what's the difference? The pwcheck
> > > > capability is not going away, so anything you have already written
> will
> > > > still work. With saslauthd, the daemon itself speaks the protocol,
> NOT
> > > > the backend mechanism. As long as the API for mechanisms doesn't
> change
> > > > (which it will/has in the SASL v2 code), we should be able to change
> the
> > > > protocol all day long without breaking the "plug-in" code.
> > > >
> > > Sorry if I displaying ignorance here, but I was under the impression
> that
> > > saslauthd is simply a daemon that _does_ use the pwcheck API, except
> that
> > > the SASL configure script happens to set it up to use a different Unix
> > > socket to normal. So if saslauthd is using char-counted strings (which I
> now
> > > understand from Lyndon's message may reduce security problems) then the
> > > pwcheck interface must be changed to use these strings. Which means that
> > > daemons already written will have to be changed to use the new string
> > > format.
> >
> > Disclaimer: I have never used/implemented pwcheck, so please verify what
> > I say, and corretc me if necessary.
> >
> > If by API, you mean the wire-protocol, then pwcheck and saslauthd _used_
> > to be the same, but I don't consider that an API. AFAIK, pwcheck
> > doesn't have an API, where saslauthd does (even though the guts of both
> > is very similar).
> >
> Yes, by API I mean wire-protocol. And my understanding is that saslauthd is
> simply a daemon that uses the pwcheck wire-protocol under the surface. There
> will not be separate pwcheck and saslauthd wire-protocols--although the
> configure script for SASL will use a different port for the saslauthd
> daemon. Therefore the changing of the wire protocol will effect existing
> pwcheck daemons.
One of the two of us is either confused or not being clear. Let's try
to put this thread to rest :^)
Your statement above is NOT correct. pwcheck and saslauthd are
completely independent of one another, and can (and will) use different
protocols (check the SASL v2 source). If you look at configure.in,
nothing prevents you from compiling support for both into a single SASL
library. This means (in theory) that Cyrus could be using saslauthd and
Sendmail could be using pwcheck.
> Note that I'm not saying this is necessarily a bad idea--I'm just trying to
> clarify the facts.
I hope this is clear enough.
> > For saslauthd, all you need to write is a single function which takes
> > the username, password, service and realm as args, verifies against the
> > LDAP server and returns a response string. saslauthd has a "plug-in"
> > interface which can be used to add any mechanism to those already
> > existing in saslauthd. The biggest difference is that implementers to
> > NOT have to worry about the wire-protocol.
>
> Yes I'm well of this. In fact my upcoming Perl pwcheck framework will offer
> exactly the same functionality. The differences will be that:
> - It will use Net::Server underneath which means a choice of
> fork-on-demand, preforking, or single process daemon models
> - No re-compilation to add/change mechs because it's Perl
> - Plug-ins written in Perl rather than C
I would consider the pwcheck support in SASL v2 for backwards
compatibility only. If I were going to write a new authentication
module/mechanism, I would do so using the saslauthd framework. Mainly
because I only need to write a single protocol-agnostic function to
interface with saslauthd.
Just my $.02
Ken
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
