On Thu, 9 Aug 2001, Devdas Bhagat wrote:
> On Thu, 09 Aug 2001, Marco Colombo spewed into the ether:
> <snip>
> > This is a completely different issue. David Wright is proposing to
> > *remove* SASL from Cyrus IMAPd in favor of a PAM-only solution, and
> > I was answering to him. I don't want SASL to be removed from IMAPd,
> Nor do I. SASL does fine for what it is supposed to do, and I don't
> believe in fixing what works.
> <snip>
> > You're asking for the opposite: to remove PAM from SASL (for LDAP auth,
> > of course) and implement a direct SASL -> LDAP solution. As I said,
> > a complete different issue.
> I'm asking for a IMAPD -> LDAP solution, not IMAPD -> SASL -> LDAP
> <snip>
> > SASL provides support for many machs. Some of them require cleartext
> > passwords to be available to the server. Where those mechs get the
> > passwords from is a mere implementation detail from the SASL engine
> > standpoint. sasldb is one easy way for mechs to get the passwords.
> So what I need is to add support to SASL according to you. But If I
> wish to bypass SASL for some reason, does it not mak e sense for the
> application to allow me to do what I need to do?
Fine. This is like saying you want an MUA -> Mail Repository solution,
and you want to bypass IMAP, for some reason. It *may* be a reasonable
request, but don't address it to IMAPd people...
The SASL library implements all client / server authentication dialog
(well, mostly: it provides hooks and uses application callbacks, if
needed). It makes sense you want to bypass it, but you're
speaking of another application, then. Other imapd server don't use
SASL.
BTW, if really OpenLDAP 2 is build on SASL, you can't really get rid
of it. You'll have an IMAPD -> LDAP -> SASL (for authentication of
the LDAP client to the LDAP server) solution.
SASL both as a protocol infrastructure and a implementation library
comes very handy to everybody that wants to add standard, extensibile
(strong) authentication support to an application. IMAPd, sendmail,
OpenLDAP developers all found SASL a viable solution when they faced
the problem to add authentication support to their application.
Asking them to drop SASL or provide a way to bypass it (which is pretty
much the same, they'll need to re-implement all the authentication
protocols from scratch) makes little sense, I believe.
> <snip>
> > LDAP API doesn't offer anything of what the SASL API does, and of
> > course the converse is also true. So you can't compare the two, as the
> > provide *completely* different services to the application. Otherwise
> > please explain me why OpenLDAP itself uses SASL.
> The LDAP API provides a convenient way of accessing sasldb over the
> network.
Then we agree B-). SASL itself does not provide a way of accessing
passwords. Some SASL methods may clients of such an facility. They
may be PAM "clients", and thus LDAP clients without even knowning it
(or kerberos, or MySQL if someone bothers to write a pam_mysql module).
Or they can be clients of a pwcheck daemon, which in turns is a LDAP
client (or getpwent(), or MySQL again)... (I like this solution more,
a deamon may run with different security credentials, with no need
to give them to every SASL application, but PAM fans may disagree).
Or they can be "clients" of a simple local /etc/sasldb database.
The point being that I see no design flaw here.
Sure we can live without SASL. Well, we did, we were able to do fancy
AAA without it. But IMAPd people decided to use it, with reasons
I think, the same reasons of sendmail and OpenLDAP people.
>
> > SASL already offers "good support for multiple authentication methods".
> > So good that even the OpenLDAP developers (as many others) chose to use
> > it to fulfill thier "multiple authentication methods" needs.
> Yes. I have nothing against SASL. What I need is a way to get access to
> authorization data from a source of my choice, bypassing the local sasl
> database/local sasl mechanisms.
So use/write a pwcheck daemon. Or a PAM module, it that fits better.
Still I see no reasons you should modify all SASL mechs to be LDAP
clients instead of using one of the above methods - but you can do it.
(pam_ldap not working it due to a bug, maybe a design flaw in the
implemetation of the SASL library - wait for the bug to be fixed or
fix it yourself, you have the source. A double-free() bug isn't a valid
reason to bypass SASL).
>
> Devdas Bhagat
> --
> If A = B and B = C, then A = C, except where void or prohibited by law.
> -- Roy Santoro
>
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ [EMAIL PROTECTED]
