[
https://issues.apache.org/jira/browse/HBASE-16141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355713#comment-15355713
]
Andrew Purtell commented on HBASE-16141:
----------------------------------------
bq. I think it's fine to have "system hooks" run with the system user
(compactions, flushes, splits, etc), whereas get/scan/etc hooks need to be run
on behalf of the calling user.
I think Gary is suggesting we make every hook run in the context of the system
user (User.runAsLoginUser()), even the RPC upcalls, and pass the request user
through in context or thread local. That's a significant departure from earlier
semantics but is very easy to reason about. We wouldn't have to sprinkle doAs()
blocks through the code as we refactor in an attempt to keep effective user
consistent as we decouple actions, make them asynchronous, or procedures, or
...
> Unwind use of UserGroupInformation.doAs() to convey requester identity in
> coprocessor upcalls
> ---------------------------------------------------------------------------------------------
>
> Key: HBASE-16141
> URL: https://issues.apache.org/jira/browse/HBASE-16141
> Project: HBase
> Issue Type: Improvement
> Components: Coprocessors, security
> Reporter: Gary Helmling
> Assignee: Gary Helmling
> Fix For: 2.0.0, 1.4.0
>
>
> In discussion on HBASE-16115, there is some discussion of whether
> UserGroupInformation.doAs() is the right mechanism for propagating the
> original requester's identify in certain system contexts (splits,
> compactions, some procedure calls). It has the unfortunately of overriding
> the current user, which makes for very confusing semantics for coprocessor
> implementors. We should instead find an alternate mechanism for conveying
> the caller identity, which does not override the current user context.
> I think we should instead look at passing this through as part of the
> ObserverContext passed to every coprocessor hook.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
