[
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.
When scheduled compactions take place there is no request user, so the logged
in user context is used, so you won't see this unless and until requests are
made from another host.
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.
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.
> 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)
