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.
The short of it is that with the patch as it stands user1 can authenticate as user1 but supply user2 as the authorization id and dovecot will fire up an imap process running as user2 looking at user2's mail.
I'm attaching a patch that I believe fixes the immediate problem but it is really only a bandaid over more general SASL issues.
The patch does the following:
- Adds in a QOP negotiation flags enum (somewhat cosmetic really)
- Renames src_name in gssapi_auth_request to authn_name and adds authz_name
- Adds a helper function to import a gss_name_t from a buffer
- Imports the authorization id (authz_name) and compares it with the authentication id (authn_name). If they are different authentication is declined.
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.