hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vihang Karajgaonkar (JIRA)" <>
Subject [jira] [Commented] (HIVE-17853) RetryingMetaStoreClient loses UGI impersonation-context when reconnecting after timeout
Date Wed, 01 Nov 2017 16:34:01 GMT


Vihang Karajgaonkar commented on HIVE-17853:

bq. Right. HS2 doesn't come into it, since this has more to do with HCatClient. The HCatalog
APIs use HiveClientCache to amortize the cost of HiveMetaStoreClient construction and metastore
connections. Systems like Oozie/Falcon that use HCatClient to make metastore-calls within
a doAs() context might land up losing their UGI.doAs() contexts after timeout, causing any
retried actions to run as a privileged, rather than the impersonated user.

Thanks [~mithun] for the clarification. I am fine with adding unit-tests in a followup JIRA.
May be we should also refactor the reconnect using UGI logic in a separate method? the {{invoke}}
method is already pretty unwieldy will the different try catch clauses. Rest looks fine to
me. +1

> RetryingMetaStoreClient loses UGI impersonation-context when reconnecting after timeout
> ---------------------------------------------------------------------------------------
>                 Key: HIVE-17853
>                 URL:
>             Project: Hive
>          Issue Type: Bug
>          Components: Metastore
>    Affects Versions: 3.0.0, 2.4.0, 2.2.1
>            Reporter: Mithun Radhakrishnan
>            Assignee: Chris Drome
>            Priority: Critical
>         Attachments: HIVE-17853.01-branch-2.patch, HIVE-17853.01.patch
> The {{RetryingMetaStoreClient}} is used to automatically reconnect to the Hive metastore,
after client timeout, transparently to the user.
> In case of user impersonation (e.g. Oozie super-user {{oozie}} impersonating a Hadoop
user {{mithun}}, to run a workflow), in case of timeout, we find that the reconnect causes
the {{UGI.doAs()}} context to be lost. Any further metastore operations will be attempted
as the login-user ({{oozie}}), as opposed to the effective user ({{mithun}}).
> We should have a fix for this shortly.

This message was sent by Atlassian JIRA

View raw message