smengcl commented on code in PR #7316:
URL: https://github.com/apache/ozone/pull/7316#discussion_r1820521610
##########
hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/multitenant/RangerClientMultiTenantAccessController.java:
##########
@@ -130,9 +130,15 @@ public
RangerClientMultiTenantAccessController(OzoneConfiguration conf)
LOG.info("authType = {}, login user = {}", authType, usernameOrPrincipal);
- client = new RangerClient(rangerHttpsAddress,
- authType, usernameOrPrincipal, passwordOrKeytab,
- rangerServiceName, OzoneConsts.OZONE);
+ UserGroupInformation loginUser = UserGroupInformation.getLoginUser();
+ try {
+ client = new RangerClient(rangerHttpsAddress,
+ authType, usernameOrPrincipal, passwordOrKeytab,
+ rangerServiceName, OzoneConsts.OZONE);
+ } finally {
+ // set back the expected login user
+ UserGroupInformation.setLoginUser(loginUser);
+ }
Review Comment:
Thanks Sammi. Good catch.
From what I understand of HDDS-11587 description, `RangerClient` shares the
same `UserGroupInformation` context with its caller (OM in this case).
Thus, when `RangerClient`'s internal Kerberos login logic generated a new
UGI and replaces the caller's LoginUser UGI, which causes the breakage (OM
stuck, failed to re-login after a while).
Questions for Ranger folks: @kumaab
1. What happens when `RangerClient`'s UGI Kerberos login expires as well? My
concern is, if `RangerClient` re-login using similar logic, the `RangerClient`
instance can get stuck for the same reason as well? Or if `RangerClient` sets
UGI again (haven't checked the impl), the OM could get stuck again for the same
reason.
3. Is there a way to isolate `RangerClient`'s internal
`UserGroupInformation` so that it doesn't leak out? Or, is it feasible to share
the same UGI with caller?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
