[Dovecot] [PATCH] Support for GSSAPI SASL Mechanism

[Jelmer Vernooij]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pod at herald.ox.ac.uk wrote:

> I believe there is a significant privacy issue with the recently
> posted updated GSSAPI patch when used on multiuser systems (indeed
> this problem is present in the previous patch as well).
>
> The username, and consequently the uid that the imap process is
> eventually run as, is taken from the authorization id in the
> (unwrapped) buffer supplied by the client as part of the SASL
> security layer negotiation.

Arrgh!! - stupid of me not having thought of this. It's actually in
the internet draft...:

"[..] and the remaining octets as the authorization identity. [..] The
server must verify that the src_name is authorized to act as the
authorization identity. After these verifications, the authetnication
process is complete."

Thanks for pointing this out.

> I'm attaching a patch that I believe fixes the immediate problem
> but it is really only a bandaid over more general SASL issues.

If you'd want to use dovecot's SASL for more advanced stuff, then
maybe, yes. I wouldn't consider this patch a bandaid though (that
sounds hackish).

> I'm not entirely happy that the username passed back from the auth
> process is still copied from the authorization id buffer because it
> feels like the username should come from gss_display_name.
> Unfortunately that will tend to return names like user at REALM which
> opens up another can of worms and is too much for my little brain
> to cope with right now.

No, what you did here is correct. The second name is the one that
should be returned to dovecot (see the internet draft).

Cheers,

Jelmer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDV8SCPa9Uoh7vUnYRAlvxAJ9I+1teJqvx0A0iAg8T4kJtGerHIgCdG0F7
OHiTxqwS4xwuJ8pN75+r52w=
=Iql/
-----END PGP SIGNATURE-----