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.
Note that I'm not saying this is necessarily a bad idea--I'm just trying to
clarify the facts.
> 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
