RE: saslauthd + pam_mysql broken ?

From: Howard Chu (hyc at highlandsun dot com)
Date: Thu Mar 25 2004 - 16:02:48 EST

  • Next message: Rob Siemborski: "RE: saslauthd + pam_mysql broken ?"

    > -----Original Message-----
    > From: owner-cyrus-sasl at lists dot andrew dot cmu dot edu
    > [mailto:owner-cyrus-sasl at lists dot andrew dot cmu dot edu]On Behalf Of Rob
    > Siemborski
    > Sent: Thursday, March 25, 2004 8:56 AM
    > To: Jeremy Rumpf
    > Cc: Igor Brezac; Roman Medina; cyrus-sasl at lists dot andrew dot cmu dot edu
    > Subject: Re: saslauthd + pam_mysql broken ?
    >
    >
    > On Thu, 25 Mar 2004, Jeremy Rumpf wrote:
    >
    > > > In my opinion, sasl lib should not alter the username to
    > begin with;
    > > > user at domain dot tld is a perfectly valid userid. In addition
    > non of the
    > > > plaintexts mech have use for the realm value like gssapi
    > and digest-md5
    > > > mechs do.
    > > >
    > >
    > > I agree as well. At this point it seems odd to have sasl
    > split foo at bar dot com up
    > > into username/realm components and then have auth_pam
    > reassemble them, but if
    > > that is the best compromise it seems sensible.
    >
    > It is unfortuinately necessary, as some saslauthd mechanisms treat the
    > realm differently than just appending it.

    re: your last comments to Bugzilla ID 2326:

    >I believe this is compliant with the specification, even if it means that
    the
    >realm= parameter ot the digest-response (and digest-challenge) is basicly
    >useless. This makes DIGEST-MD5 consistant with every other mechanism (yes,
    >KERBEROS_V4 and GSSAPI have a slightly different concept, but the execution
    in
    >this case is the same -- split at the @ sign). It also allows *all*
    mechanims
    >to support realms.

    Rendering the DIGEST-MD5 "realm" parameter useless does not seem like a
    positive thing to do. If it is truly useless, it shouldn't have been in the
    spec. Since it is in the spec, there is probably an implementation out there
    that depends on using it, and Cyrus' behavior will interfere with
    interoperability in that case.

    >I certainly do NOT agree that we should change how realms are handled in the
    >mechanisms that do not internally support realms. And I don't agree that we
    >should handle DIGEST differently from the rest (someone else is free to
    write a
    >3rd party plugin to do that).

    >Now, I *could* understand an argument that we shouldn't be doing *anything*
    >about realms in the processing of the identifier, and instead just passing
    the
    >identifier back to the calling application wholesale (and, again, in
    >DIGEST-MD5's case, advertising and accepting only one realm). I don't see
    this
    >behavior changing outside of a minor version bump though (and I'm not really
    in
    >love with it anyway).

    This sounds to me like the best solution. Ultimately the calling application
    is the one that most knows how an identity is going to be used. The SASL
    library should just be transparent here, and pass the name the user provided
    verbatim. Again, since the specs don't mention using realms in most of these
    mechs, it isn't right for the SASL library to presume their usage. It is fine
    for an application to parse and use realms if it wishes.

    >I can also understand an argument that we should be disallowing user_realm
    >values with an '@' sign.

    And this also contradicts the spec that explicitly states that '@' is a valid
    character in a realm name. Once again, taking this position will break
    interoperability.

      -- Howard Chu
      Chief Architect, Symas Corp. Director, Highland Sun
      http://www.symas.com http://highlandsun.com/hyc
      Symas: Premier OpenSource Development and Support


  • Next message: Rob Siemborski: "RE: saslauthd + pam_mysql broken ?"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD