From: [email protected]

If you want to authenticate people against Kerberos with saslauthd,
you can simply use the kerberos5 mechanism instead of PAM. At least it
appears to work fine for me. This is of course assuming that you don't
need any other PAM modules or options, but I don't see why anyone
would need that in the case of saslauthd.

--
Pelle


--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

On Aug 18, 2004, at 3:14 AM, Per Olofsson wrote:

If you want to authenticate people against Kerberos with saslauthd,
you can simply use the kerberos5 mechanism instead of PAM. At least it appears to work fine for me. This is of course assuming that you don't
need any other PAM modules or options, but I don't see why anyone
would need that in the case of saslauthd.

You're absolutely correct; but you are assuming no other PAM modules
are in use. I'm using a common PAM stack, including other
authentication modules, for all services. This conflict feels to me
like a bug, rather than a feature.

I've since built sasl2-bin without heimdal-dev or libkrb5-dev; this
also corrected the problem. I'm thinking perhaps cyrus-sasl2 should be
further subdivided into cyrus-sasl2-mit (libsasl2-modules-gssapi-mit, libsasl2-modules-krb4-mit), cyrus-sasl2-heimdal (libsasl2-modules-gssapi-heimdal, libsasl2-modules-krb4-heimdal), &
cyrus-sasl2 (sasl2-bin, etc.) I haven't checked the effect of building sasl2-bin without heimdal-dev or libkrb5-dev on the kerberos5 saslauthd mechanism. Perhaps sasl2-bin-mit & sasl2-bin-heimdal are necessary?

Could a symbol clash be avoided, without changing sasl2-bin's build dependancies?

Thank you for your interest in this problem!

Jack



--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)

From: [email protected]

[email protected]:

You're absolutely correct; but you are assuming no other PAM modules
are in use. I'm using a common PAM stack, including other
authentication modules, for all services. This conflict feels to me
like a bug, rather than a feature.

Well, yes, it's a bug. I just wanted to share a workaround :)

I've since built sasl2-bin without heimdal-dev or libkrb5-dev; this
also corrected the problem. I'm thinking perhaps cyrus-sasl2 should be further subdivided into cyrus-sasl2-mit (libsasl2-modules-gssapi-mit, libsasl2-modules-krb4-mit), cyrus-sasl2-heimdal (libsasl2-modules-gssapi-heimdal, libsasl2-modules-krb4-heimdal), & cyrus-sasl2 (sasl2-bin, etc.) I haven't checked the effect of building sasl2-bin without heimdal-dev or libkrb5-dev on the kerberos5 saslauthd mechanism. Perhaps sasl2-bin-mit & sasl2-bin-heimdal are necessary?

Could a symbol clash be avoided, without changing sasl2-bin's build dependancies?

Yes. This can be done by changing MIT Kerberos and Heimdal to use
versioned symbols. When libraries use versioned symbols, it's possible
to link different versions of them to the same binary. This would
solve the problem in an elegant but, unfortunately, non-trivial way.

--
Pelle


--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)