[
https://issues.apache.org/jira/browse/HADOOP-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648337#comment-16648337
]
Hrishikesh Gadre commented on HADOOP-9567:
------------------------------------------
[~jojochuang] thanks for the review.
{quote}Supportability: it would be really helpful if there is a way to tell if
the user will renew keytab automatically, or if it will renew tgt automatically.
{quote}
I will improve logging so that it will clearly say if the keytab based
auto-renewal at UGI level is enabled or not.
{quote}What if UGI#getLogin() is called (assuming the user already performed
kinit, and getLogin() will login with tgt), followed by
UGI#loginUserFromKeytab()? It seems the latter doesn't get renewed.
{quote}
Note that invocation of loginUserFromKeytab() API will replace the currently
logged-in user with the one based on keytab. So the auto renewal of keytab
based login will indeed happen.
[https://github.com/apache/hadoop/blob/85ccab7d3f87b71170e4f71c76f5663d1fe34886/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/UserGroupInformation.java#L1010]
The problem is ticket cache based login spawns the auto-renewal thread by
default and that thread is never stopped during the lifetime of JVM. So in this
case, both these threads will be active at the same time - one updating ticket
cache based UGI and other updating keytab based UGI.
Note: this is a fundamental limitation of current design of UGI class in that
it does not provide a way to shutdown the auto renewal thread once the current
login UGI object is replaced with other object. How likely is this scenario in
practice though? Typically applications will use one way or the other...
{quote}What should be expected if a user calls UGI#loginUserFromKeytab()
multiple times? From the code it looks like only the first login user will be
renewed. If the process calls loginUserFromKeytab() the second time, the user
doesn't get renewed.
{quote}
No. Every invocation of loginUserFromKeytab will create a new UGI instance
(associated with a dedicated thread for auto renewal) and replace the current
loginUser reference with the new one. As I mentioned above, the problem here is
that the auto-renewal of previous UGI instance would continue until the
lifetime of JVM. This could be a problem if user calls loginUserFromKeytab many
times thereby creating a new thread for each UGI instance. How likely is this
scenario in practice? With keytab auto renewal enabled, I would expect
application to invoke this API only once.
> Provide auto-renewal for keytab based logins
> --------------------------------------------
>
> Key: HADOOP-9567
> URL: https://issues.apache.org/jira/browse/HADOOP-9567
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Affects Versions: 2.0.0-alpha
> Reporter: Harsh J
> Assignee: Hrishikesh Gadre
> Priority: Minor
> Attachments: HADOOP-9567-001.patch, HADOOP-9567-002.patch,
> HADOOP-9567-003.patch, HADOOP-9567.branch-2.7.001.patch
>
>
> We do a renewal for cached tickets (obtained via kinit before using a Hadoop
> application) but we explicitly seem to avoid doing a renewal for keytab based
> logins (done from within the client code) when we could do that as well via a
> similar thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
