[Dovecot] [PATCH] Support for GSSAPI SASL Mechanism

Jelmer Vernooij jelmer at samba.org
Wed Oct 19 16:45:17 EEST 2005


On Wed, Oct 19, 2005 at 02:11:14PM +0100, pod at herald.ox.ac.uk wrote about 'Re: [Dovecot] [PATCH] Support for GSSAPI SASL Mechanism':
> >>>>> "JV" == Jelmer Vernooij <jelmer at samba.org> writes:
>     JV> Attached is a patch against current CVS that adds support for the
>     JV> GSSAPI SASL mechanism. It was written from scratch, after reading
>     JV> the patch from Colin Walters against a much older version of
>     JV> dovecot.
> I too have been working on getting a working GSSAPI patch against current
> CVS and have taken a similar approach.
Yeah, Timo mentioned there was someone else working on a new patch
when I first talked to him yesterday evening, but I already had everything 
working by then, except for the configuration options, so I decided to go 
ahead. What's the status of your patch?

> Any idea if this is going to make it's way into CVS?
I hope so :-) 

> I notice that its auth only and you don't have any SASL security layer
> integrity or protection stuff, same as DIGEST-MD5.  
I've focussed on authentication only for now since it keeps the patch 
small and readable (and thus is hopefully more easily accepted into
CVS). Just authentication is sufficient for a lot of people.

Integrity and protection support can always be added later on by adding
a couple of functions in mech-gssapi.c (and the right infrastructure
in dovecot). 

> This is the point
> which I've got to and have been considering how to implement the
> 'integrity-proxy' (name coined from the Colin Walters patch) part of
> things.  Work on this would have implications for mech-digest-md5.c as
> well.
Yeah, that's a tricky. Especially when doing it in a way that has to
be usable for more mechanisms.

> Want to discuss ideas?

> I have been considering:

>  - start up two pipe connected processes, a network filter and
>    libexec/dovecot/imap, the filter does the gss_wrap, gss_unwrap etc
>  - create a io library filter layer
This sounds like the sanest way of handling this to me. You'd have to
export the GSS security context from the login process to the user
process somehow, but that shouldn't be a problem with
gss_{ex,im}port_sec_context(). 

>  - keep the imap-login process around but have it re-exec as the filter
>    (would be running as login_user, probably not ideal)

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://dovecot.org/pipermail/dovecot/attachments/20051019/42efb9cf/attachment.pgp


More information about the dovecot mailing list