[
https://issues.apache.org/jira/browse/HBASE-16115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354413#comment-15354413
]
Gary Helmling commented on HBASE-16115:
---------------------------------------
{quote}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.{quote}
Hmm, why do we wrap the compaction upcalls in a User.doAs() in the first place?
I understand that we want to authorize the compaction request as the user who
initiated it, but is User.doAs() the right mechanism? It seems like we want
something more akin to RpcCallContext to stash the authenticated user making
the request, instead of using User.doAs() just so that User.getCurrent() can be
hacked to return the requesting user's identity. This seems like a very
confusing semantic to handle for anyone writing a coprocessor. For contrast,
we don't use User.doAs() to authorize normal RPC requests for most of the other
pre/post upcalls. Since coprocessors are a system extension mechanism, I don't
see why they should be executing as anything other than the system user.
I would also suggest that the reliance on doAs() for the procedure code
authorization checks may not be what we want there either. Since carrying
through the requesting user is a requirement of the security code, it seems
like the security code should handle it, rather than muddying the behavior for
all coprocessors. Or maybe it is time to finally pull AccessController up out
of the coprocessor APIs and more tightly integrate it, so that we can avoid
this kind of conflict over requirements.
In any case, it seems like an alternate approach to passing the user
credentials would avoid the confusing semantics entirely, while perhaps
bleeding through the abstraction a bit for the security code.
> 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)
