hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4263) New config property for user-table only RegionObservers.
Date Sat, 27 Aug 2011 08:57:29 GMT

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

Andrew Purtell commented on HBASE-4263:

Coprocessors in architecture and implementation are exactly like loadable kernel modules.
I think this moots considerations for restricting them.

We did discuss code weaving in security policy earlier, but I'm not sure how fruitful pursuing
that would be, given the complexity involved and the murky assurance that would be the result.

We can distinguish between external and internal coprocessors with HBASE-4047. If you want
to pursue a direction where coprocessors can meaningfully be treated with some suspicion or
restriction, adding security policies for "external" coprocessors makes sense. How policy
is implemented there should be pluggable and stackable. It should be possible to supply a
basic set of options for users, and allow system integrators to add their own, and stack them
in order of desired authority.

> New config property for user-table only RegionObservers.
> --------------------------------------------------------
>                 Key: HBASE-4263
>                 URL: https://issues.apache.org/jira/browse/HBASE-4263
>             Project: HBase
>          Issue Type: Bug
>          Components: coprocessors
>    Affects Versions: 0.92.0
>            Reporter: Lars Hofhansl
>            Priority: Minor
>             Fix For: 0.92.0
> It turns out that a RegionObserver can interfere with - ROOT - and .META.
> That seems weird and should be prevented.
> (The one use case for this that I could come up with is access control by Region by intercepting
actions on .META., and I don't think that's a particularly strong use case).
> I'll attach a patch as soon as I get to it.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message