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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
