[Dovecot] [PATCH] GSSAPI authorization and virtual users
The attached patch makes it possible for Kerberos principals to be associated with a password database entry by adding a new "k5principals" passdb setting. A client that successfully authenticates using GSSAPI will be able to log in as any user who has been associated with the client's Kerberos principal. This means that users can now use their Kerberos identities to access virtual mail accounts.
The patch definitely needs review by someone familiar with Dovecot. It works for me on a small test installation using the passwd-file backend.
Things that should probably be improved:
1. The list of authorized principals is stored in struct
auth_request. I would prefer to store it in struct
gssapi_auth_request, but auth-request.c does not know about
structs that are specific to the different authentication
plugins. This could be fixed in a more general way by adding a
new function to struct mech_module to allow authplugins to read
fields during passdb lookups.
2. The gssapi authplugin now does a credential lookup in order to
trigger parsing of the k5principals setting. In order for this
to work, auth_request_set_username is now called before
mech_gssapi_userok. AFAICT the only impact of this is that
messages logged by this function (and the functions it calls)
will now use the name of the virtual account.
3. The credentials lookup triggers an info log message saying that
credentials for GSSAPI were requested, "but we have only (e.g.)
MD5-CRYPT". The authplugin doesn't actually want the credential,
but I think that the only way the authplugin can trigger a
passdb lookup is by requesting it.
4. The final part of the code in mech_gssapi_unwrap was moved to
the callback that's triggered when the credentials lookup is
complete. The code still needs access to the GSSAPI data, so the
buffer pointer & length are now stored in struct
gssapi_auth_request, making the inbuf parameter to the
mech_gssapi_{sec_context,wrap,unwrap} functions superfluous. The
parameters should be removed.
5. The k5principals list won't be processed on Solaris. The code
added to the end of mech_gssapi_krb5_userok would have to be
moved to a separate function and then be called from the Solaris
code.
6. GCC tells me about assignment to incompatible pointer types in
the code that iterates through gssapi_k5principals. I must be
missing something.The patch is licensed under the MIT license. Please let me know what you think.
-- Sam Morris sam@robots.org.uk
On 5.3.2012, at 20.45, Sam Morris wrote:
3. The credentials lookup triggers an info log message saying that credentials for GSSAPI were requested, "but we have only (e.g.) MD5-CRYPT". The authplugin doesn't actually want the credential, but I think that the only way the authplugin can trigger a passdb lookup is by requesting it.
I'll look at the rest more closely later, but this should be an easy fix: request "" instead of "GSSAPI".
On Mon, 2012-03-05 at 20:52 +0200, Timo Sirainen wrote:
On 5.3.2012, at 20.45, Sam Morris wrote:
3. The credentials lookup triggers an info log message saying that credentials for GSSAPI were requested, "but we have only (e.g.) MD5-CRYPT". The authplugin doesn't actually want the credential, but I think that the only way the authplugin can trigger a passdb lookup is by requesting it.I'll look at the rest more closely later, but this should be an easy fix: request "" instead of "GSSAPI".
Thanks for pointing that out. Here's a newer version of the patch with that change. I also realised that the gss_buffer is not required in the code that runs once the passdb lookup is complete, so I removed the code that stashes it in struct gssapi_auth_request.
Regards,
-- Sam Morris sam@robots.org.uk
On Tue, 2012-03-06 at 18:12 +0000, Sam Morris wrote:
On Mon, 2012-03-05 at 20:52 +0200, Timo Sirainen wrote:
On 5.3.2012, at 20.45, Sam Morris wrote:
3. The credentials lookup triggers an info log message saying that credentials for GSSAPI were requested, "but we have only (e.g.) MD5-CRYPT". The authplugin doesn't actually want the credential, but I think that the only way the authplugin can trigger a passdb lookup is by requesting it.I'll look at the rest more closely later, but this should be an easy fix: request "" instead of "GSSAPI".
Thanks for pointing that out. Here's a newer version of the patch with that change. I also realised that the gss_buffer is not required in the code that runs once the passdb lookup is complete, so I removed the code that stashes it in struct gssapi_auth_request.
I finally looked into this and did some changes. Does it still work? :) http://hg.dovecot.org/dovecot-2.2/rev/183adc90781c
On Wed, 2012-06-27 at 12:04 +0300, Timo Sirainen wrote:
On Tue, 2012-03-06 at 18:12 +0000, Sam Morris wrote:
On Mon, 2012-03-05 at 20:52 +0200, Timo Sirainen wrote:
On 5.3.2012, at 20.45, Sam Morris wrote:
3. The credentials lookup triggers an info log message saying that credentials for GSSAPI were requested, "but we have only (e.g.) MD5-CRYPT". The authplugin doesn't actually want the credential, but I think that the only way the authplugin can trigger a passdb lookup is by requesting it.I'll look at the rest more closely later, but this should be an easy fix: request "" instead of "GSSAPI".
Thanks for pointing that out. Here's a newer version of the patch with that change. I also realised that the gss_buffer is not required in the code that runs once the passdb lookup is complete, so I removed the code that stashes it in struct gssapi_auth_request.
I finally looked into this and did some changes. Does it still work? :) http://hg.dovecot.org/dovecot-2.2/rev/183adc90781c
Works fine, thanks!
-- Sam Morris sam@robots.org.uk
participants (2)
-
Sam Morris
-
Timo Sirainen