[
https://issues.apache.org/jira/browse/ACCUMULO-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved ACCUMULO-4665.
----------------------------------
Resolution: Fixed
> 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
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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)