Jeremy Howard wrote:
>
> <cc'd to cyrus-sasl>
> Ken Murchison wrote:
> <...rather long thread where Ken and I confuse each other greatly
> snipped...>
> > One of the two of us is either confused or not being clear. Let's try
> > to put this thread to rest :^)
> >
> Sorry, no such luck yet :-( You can reply to this off-list if you think this
> is getting out of control--although so far we seem to be getting somewhere
> so maybe the discussion is good for the archives...
>
> > 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.
> >
> According to Christopher Audley in the message:
> http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrus&msg=10
> 234:
> ----
> To the core sasl library, it looks just like pwcheck. Open a UNIX socket,
> pass in 'username\0password\0' and get back 'OK' or something else.
> saslauthd defaults to putting its socket in a different location from
> pwcheck, but it has a command line switch you can use to emulate pwcheck
> behavior.
>
> Because the protocol is essentially the same as pwcheck, you can lift
> saslauthd from a latter version of SASL and use it with your 1.5.24 SASL
> installation
This is all true with SASL v1.5 ONLY!!! This will not be the case in
SASL v2! I would consider the fact that saslauthd can be used as a
pseudo-pwcheck daemon in v1.5 a temporary hack and should not be
something that people should depend on.
> ----
> Sure, you can "compile support for both", but all that means is you can have
> two different unix sockets for two different SASL-using apps. Of course
> Christopher's description above now needs to be updated to say "pass in
> '<count>username<count>password<count>service<count>realm' and get back
> '2OK' or something else". Now if we do change to that different wire
> protocol, I strongly suggest that it be changed for both the saslauthd _and_
> the pwcheck sockets. Making that different would just be confusing, and
> would mean that pwcheck daemons would not be able to take advantage of the
> realm and service parameters.
If we make the same change to pwcheck, then all existing pwcheck daemons
will be broken. This is something that is clearly distasteful. This is
why I made the statement below.
I really don't see the need to have the two protocols the same. SASL v2
is moving towards saslauthd for plaintext password verification.
pwcheck support is being maintained so that existing pwcheck daemons
will continue to work out the box with SASL v2. They are simply
different backends (along with sasldb) for the server side of SASL to
verify plaintext passwords.
> > I would consider the pwcheck support in SASL v2 for backwards
> > compatibility only.
> >
> Maybe we need a distinction between "pwcheck-socket-support" which is the
> ability to tell SASL to contact a Unix socket to authenticate, versus
> "pwcheck-shadow-daemon" which is the pwcheck daemon that comes with SASL 1.x
> for authenticating against the shadow file.
>
> The pwcheck-shadow-daemon is clearly redundent with saslauthd, because it is
> less flexible and less scalable.
Agreed. The pwcheck-shadow-daemon is distributed as a working example
of a pwcheck daemon. The shadow support in saslauthd will mostly likely
be that which is used by default in SASL v2.
> The pwcheck-socket-support is (I don't think) for "backwards compatibility
> only". It is the very wire protocol that saslauthd uses.
This is only true in v1.5. It will NOT be the case in v2.
> > 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.
>
> If I were going to write a new authentication module/mechanism, I would do
> so using the Perl-pwcheck framework. With this I only need to write a single
> protocol-agnostic function to interface with the Perl-pwcheck framework. I
> also get the benefits I mentioned in my last message (choice of forking
> models, no re-compilation, use of Perl rather than C). Note that this
> framework is not released yet, since I want to clarify these issues as they
> may effect the interface of Perl-pwcheck.
Nothing is stopping you from continuing to develop against the pwcheck
interface. If you don't like the forking model currently in saslauthd,
submit a patch which makes it better, or continue to move in your
current direction.
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
