kdc: cross realm s4u2self handling
Greg Hudson
ghudson at mit.edu
Tue Sep 18 17:27:40 EDT 2018
On 09/18/2018 12:12 PM, Isaac Boukris wrote:
> I'd like to start with the last commit in the MIT patch, which
> partially reverts 8a9909ff9ef6b51c5ed09ead6713888fbb34072f commit,
> that I don't fully understand.
That was part of a series of commits made between 1.11 and 1.12, with
the goal of treating the client request as an immutable object (commit
9e37d01a0122904776fada43ec65425c375414d8). Prior to those commits,
process_tgs_req() would set the request server to the result of the
server search, which could be a referral. For the commit you are trying
to understand, there were two checks against request->server that I was
concerned with:
* In kdc_util.c:kdc_process_s4u2self_req(), we compare request->server
against the client principal in the header ticket and error out if it
doesn't match.
* In tgs_policy.c:check_tgs_nontgt(), we compare the header ticket
server against the request server and error out if it doesn't match.
I wanted to make sure that leaving request->server alone would not allow
requests through which would previously have been disallowed. I was
only considering within-realm S4U2Self requests, but I believe that in
the 1.11 code, the check in kdc_process_s4u2self_req() would have
prevented cross-realm S4U2Self requests from succeeding. It no longer
interferes bequest request->server is now the original request server.
I may have unwittingly been preserving a bug rather than an intentional
restriction, so we can probably relax it.
More information about the krbdev
mailing list