Simon Josefsson <[EMAIL PROTECTED]> 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 _______________________________________________ lsh-bugs mailing list [EMAIL PROTECTED] http://lists.lysator.liu.se/mailman/listinfo/lsh-bugs
