[ 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)