-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
pod@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@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-----