[
https://issues.apache.org/jira/browse/HBASE-16115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354549#comment-15354549
]
Gary Helmling commented on HBASE-16115:
---------------------------------------
Yes, I was looking at HBASE-14475 as well while tracing back the origin of
this. The context of that seems specific to security auditing of the
compaction request, which was a valid issue, but I don't think implies any
expectations of the executing user context for other coprocessors. I agree
with the sentiment of it and HBASE-14686, I'm just not sure in hindsight that
we reached the best implementation.
I think that using an alternate mechanism for conveying that caller context
would avoid conflicting with the current user and possibly be more consistent
with the RpcCallContext. Maybe it would be better to pass through the
requester as part of the ObserverContext. That is present for each coprocessor
hook and already prepared for each upcall. If anything, this seems like it
belongs there. We could even shim in a call to RpcCallContext where
appropriate so this would consistently provide the requester identity for all
upcalls.
bq. My concern here is we don't ask Phoenix or other implementations to change
back and forth for this twice in 0.98.
I generally agree with this as well, but it's your call.
> 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)
