On 2013-01-07 at 20:34 +0000, Andy Bennett wrote:
> ...it suggests that MIT Kerberos might do something useful at the point
> that the client keytab is chosen. I don't know how that works in the
> Debian build that I have tho'.
This is one of those areas where testing is the best solution, because
the documentation tends to not cover this well.
> ...so I could provide client support for the cyrus-sasl authenticator.
> The issue of linkage to the appropriate Kerberos libraries is then a
> problem for the system's Cyrus SASL installation. On Debian this is
> handled through the optional installation of the following two modules:
Yes; there's also GSASL, supported in Exim since 4.80, also server-side,
and written by me just before I wrote heimdal_gssapi; I was hoping to
find a way to handle keytab specification with GSASL.
If it works for you with MIT Kerberos, excellent. :)
> I found these threads:
>
> http://kerberos.996246.n3.nabble.com/Exim-Heimdal-1-4-server-identity-lost-KRB5-KTNAME-redux-tt11607.html#none
>
> http://kerberos.996246.n3.nabble.com/Patch-for-uid-based-default-keytabs-for-sasl-gssapi-slapd-ldap-td10925.html
>
> The latter suggests that they are thinking about fixing (or have now
> fixed) this in a similar way to the MIT Kerberos client keytab
> documentation above. Therefore a patch to heimdal_gssapi may involve
> long term code duplication and maintenance in exim.
The first of those two threads was me posting what I had found, in early
2012, and is what directly led to my writing the heimdal_gssapi
authenticator for Exim because there was no response.
The second is from Harry Coin, in September 2011, _before_ my posting,
but led to an epic thread, which I tuned out of. I don't think they've
fixed it since.
Note that there's no real fix there: the default paths for the keytabs
do not vary by uid, only the key cache, and [libdefaults] can't be
overriden on a per-app basis. Ideally, the SASL service name would be
propagated into the GSSAPI invocation which would propagate down to
Kerberos and result in the SASL service name being available as a
section name in krb5.conf. I'm not aware of that happening, ever.
For _client_ usage, it's likely that just writing the cyrus_sasl/gsasl
bindings for Exim to driver client authenticator usage would work, with
defaults. The problems arise server-side, using a program that is not
running as root when accessing the keytab but is setuid; heimdal_gssapi
was the best solution I could find which provided a degree of system
security.
I think that, if you want to deal with the mental overhead of dealing
with the SASL libraries while writing client support, then as the person
doing the work, it's entirely your call; but for patches to be accepted
into Exim, reducing your future maintenance burden, the SASL stuff would
need to work for the various different ways of driving SASL, with things
like options to provide passwords, etc. I suspect that this is far more
than you want to do ... but if you're willing, we'd very gladly accept
such patches. :)
For minimising the amount of work and testing to get the code written,
clearly working and feature complete within the interfaces claimed to be
offered, the heimdal_gssapi route is _likely_, in my estimation, to be
simplest.
But the SASL drivers would be more generally useful to more people.
It's a trade-off. Heck, I don't even know if you're planning/able to
provide the patches back upstream to us, I'm just being optimistic.
Regards,
-Phil
