Simon Josefsson jas@extundo.com writes:
Right, what I was looking for was something similar to
connection->user = USER_LOOKUP(self->gssapi->db, authid, authzid);
where authid was the GSS authenticated user (e.g., "jas") and authzid the username received from the first USERAUTH_REQUEST (e.g., "root").
lshd cares only about the username provided in the USERAUTH_REQUEST, and the passwd-information (uid, loginshell, etc) in the user object returned by the userauth method. These are generally expected to match.
For the case of a user, "jas", logging in as root (for kerberos, that means that "jas" is listed in a file in root's home directory, IIRC), I would expect the USERAUTH_REQUEST to request login for "root", and the information that you want to use tickets belonging to "jas" should be somewhere inside the gss-api or kerberos messages, and then I can view it as an internal detail of the gss-api mechanism. Checking that "jas" is allowed to login as root should be the resposibility of the gss-api userauth method.
I think it's possible for a userauth method to turn a USERAUTH_REQUEST for the user "jas" into a user object that represents "root", but that seems fishy to me. I prefer to not have the username -> user mapping depend on the particular userauth method that is used.
Regards, /Niels