<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
----
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.
> 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.
The pwcheck-socket-support is (I don't think) for "backwards compatibility
only". It is the very wire protocol that saslauthd uses.
> 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.
