[jira] [Comment Edited] (HBASE-16115) Missing security context in RegionObserver coprocessor when a compaction/split is triggered manually

["Andrew Purtell (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-16115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354186#comment-15354186 ] 

Andrew Purtell edited comment on HBASE-16115 at 6/29/16 1:42 AM:
-----------------------------------------------------------------

Funny, I was just writing up commentary for our internal issue tracker.

No [~lhofhansl], I think [~devaraj] and [~enis] are correct. I added debug logging around the coprocessor upcalls just to be sure. The upcalls are invoked with the credential of the requesting user, which is different from the locally logged in user. That's what we want for security when the AccessController is installed; and we don't want any other coprocessor naively attempting RPC with this security context. The semantics of the upcall seem correct. Phoenix isn't taking this into account. I think the fix is for Phoenix to save off the result of User.getCurrent() at init time and do a doAs() with that UGI whenever attempting RPC. At the same time this is very poorly documented, so that's an action item for HBase too: All coprocessor upcall javadoc should be annotated with the expected security context.


was (Author: apurtell):
Funny, I was just writing up commentary for our internal issue tracker.

No [~lhofhansl], I think [~devaraj] and [~enis] are correct. I added debug logging around the coprocessor upcalls just to be sure. The upcalls are invoked with the credential of the requesting user, which is different from the locally logged in user. That's what we want for security when the AccessController is installed; and we don't want any other coprocessor naively attempting RPC with this security context. The semantics of the upcall seem correct. Phoenix isn't taking this into account. I think the fix is for Phoenix to save off the result of User.getCurrent() at init time and do a doAs() with that UGI whenever attempting RPC. At the same time this is very poorly documented, so that's an action item for HBase too. 

> Missing security context in RegionObserver coprocessor when a compaction/split is triggered manually
> ----------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-16115
>                 URL: https://issues.apache.org/jira/browse/HBASE-16115
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.98.20
>            Reporter: Lars Hofhansl
>
> We ran into an interesting phenomenon which can easily render a cluster unusable.
> We loaded some tests data into a test table and forced a manual compaction through the UI. We have some compaction hooks implemented in a region observer, which writes back to another HBase table when the compaction finishes. We noticed that this coprocessor is not setup correctly, it seems the security context is missing.
> The interesting part is that this _only_ happens when the compaction is triggere through the UI. Automatic compactions (major or minor) or when triggered via the HBase shell (folling a kinit) work fine. Only the UI-triggered compactions cause this issues and lead to essentially neverending compactions, immovable regions, etc.
> Not sure what exactly the issue is, but I wanted to make sure I capture this.
> [~apurtell], [~ghelmling], FYI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)