Josh Elser created ACCUMULO-4665:
------------------------------------
Summary: Must use the "real" User for RPCs when Kerberos is
enabled.
Key: ACCUMULO-4665
URL: https://issues.apache.org/jira/browse/ACCUMULO-4665
Project: Accumulo
Issue Type: Bug
Components: rpc
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Critical
Fix For: 1.7.4, 1.8.2, 2.0.0
In the normal Kerberos authentication case, a User(GroupInformation) has a
username and a set of credentials for that user. This is the typical case
because a user is accessing Accumulo from their local machine or a machine
where they can obtain a Kerberos ticket from the KDC.
However, there are certain situations where another service is accessing
Accumul on behalf of the end-user. We do not want to share our ticket
(password) with the service for security reasons, but would still like this
service to be able to access Accumulo on our behalf. We refer to this as
"proxy-user authentication" or "impersonation".
The Accumulo Proxy is a common scenario for this: an end-user {{josh}} with
Kerberos credentials authenticates to the Accumulo proxy (who is running as
{{proxyserver}}). The Proxy then authenticates to Accumulo as {{josh}} even
though its credentials are for {{proxyserver}}. We refer to this as {{josh}} is
proxied on {{proxyserver}}.
Down in ThriftUtil, we pull the current UGI and use that to automatically wrap
any Thrift RPCs in a doAs() call to ensure that Thrift can access the Kerberos
credentials to perform the SASL authentication handshake. The problem is that
when we have a proxy-user scenario, the Thrift RPC doesn't have access to the
credentials and fails.
The fix is rather simple: make sure that we always use the "real" user that has
kerberos credentials, not any "proxy" user.
I came across this problem re-testing some integration of the Hive-Accumulo
integration with Hiveserver2 (which plays the same role as the Accumulo Proxy
as described above).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
