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

Lars Hofhansl commented on HBASE-16115:
---------------------------------------

bq. Since coprocessors are a system extension mechanism, I don't see why they 
should be executing as anything other than the system user.

That's my thinking too.

When a coprocess hook is executed as result of a compaction that is a system 
extension. As such why would such a hook care whether the compaction was 
triggered by the region server itself or via the master on behalf of a user? 
Putting this on the coprocessor implementer seems onerous.

Now there are other hooks ({pre|post}{Get|Scan} etc) that are clearly on behalf 
of a user... Or are they?

We introduced the extra doAs in patch releases (1.0.3, 1.1.3, and 0.98.16). 1.0 
and 1.1 are or will be retired, right? So maybe we fix it only on 0.98, 1.4, 
and 2.0.


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

Reply via email to