hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-16115) Missing security context in RegionObserver coprocessor when a compaction/split is triggered manually
Date Wed, 29 Jun 2016 01:44:27 GMT

    [ 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:44 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.

This obviously doesn't impact compactions normally. Core code is executed in the context of
the logged in user. We switch contexts only for the upcalls. 


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: All coprocessor upcall
javadoc should be annotated with the expected security context.

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

Mime
View raw message