I was looking at a problem a coworker had.
He was unable to create any tables in HBase.

As it turned out he had created a RegionObserver and loaded it at HBase start, which (as a test) just returned empty scanners from postOpenScanner(...).
(In our case we will eventually have at least some clusters that will implement certain operators through RegionObservers for every table.)
That led me to question: Should a RegionObserver be allowed to interfere with the system tables?

Opinions?
-- Lars

On Fri, Aug 26, 2011 at 8:58 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
> That led me to question: Should a RegionObserver be allowed to interfere with the system tables?
>
> Opinions?
>
>

I'd think no.
St.Ack

Its one think mucking up your user-space tables but catalog tables are
a different story.
St.Ack

On Fri, Aug 26, 2011 at 9:29 PM, Stack <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 26, 2011 at 8:58 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>> That led me to question: Should a RegionObserver be allowed to interfere with the system tables?
>>
>> Opinions?
>>
>>
>
> I'd think no.
> St.Ack
>

The only use case I can think of is to use a region observer to control access on a Region level by intercepting actions on the .META. table, but that seems far fetched.

I'll file a case and come up with a patch.

-- Lars

________________________________
From: Stack <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
Sent: Friday, August 26, 2011 9:30 PM
Subject: Re: RegionObserver and system tables (-ROOT-, .META.)

Its one think mucking up your user-space tables but catalog tables are
a different story.
St.Ack

On Fri, Aug 26, 2011 at 9:29 PM, Stack <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 26, 2011 at 8:58 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>> That led me to question: Should a RegionObserver be allowed to interfere with the system tables?
>>
>> Opinions?
>>
>>
>
> I'd think no.
> St.Ack
>

> That led me to question: Should a RegionObserver be allowed to interfere
> with the system tables?
>
>
Yes.

This is critical for the security implementation, for example.  We need to
perform authorization checks on access to -ROOT- and .META.  If this were
disallowed, then security couldn't be implemented on coprocessors alone.
I'm sure there are other applications lurking out there as well.

Coprocessors are very much an "experts only" feature right now.  It's
possible to completely bork your cluster with them.  We can make them a bit
safer to use, but going too far and neutering them only shoots ourselves in
the foot.

--gh

I see... Could you comment on HBASE-4263?

What I am suggesting there is to only load table specific RegionObservers for -ROOT- and .META. and not system the wide ones.
As coprocessors for these two tables will likely have to be special anyway that might make sense.
-- Lars

________________________________
From: Gary Helmling <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Friday, August 26, 2011 9:44 PM
Subject: Re: RegionObserver and system tables (-ROOT-, .META.)

> That led me to question: Should a RegionObserver be allowed to interfere
> with the system tables?
>
>
Yes.

This is critical for the security implementation, for example.  We need to
perform authorization checks on access to -ROOT- and .META.  If this were
disallowed, then security couldn't be implemented on coprocessors alone.
I'm sure there are other applications lurking out there as well.

Coprocessors are very much an "experts only" feature right now.  It's
possible to completely bork your cluster with them.  We can make them a bit
safer to use, but going too far and neutering them only shoots ourselves in
the foot.

--gh

Coprocessors in architecture and implementation are exactly like loadable kernel modules. This moots this discussion. :-)

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.

If you want to pursue a direction where coprocessors can meaningfully be treated with some suspicion or restriction, look for the jira I opened for an external coprocessor host. Adding security policies there would make sense.

On Fri Aug 26th, 2011 9:58 PM PDT lars hofhansl wrote:

>I see... Could you comment on HBASE-4263?
>
>What I am suggesting there is to only load table specific RegionObservers for -ROOT- and .META. and not system the wide ones.
>As coprocessors for these two tables will likely have to be special anyway that might make sense.
>
>
>-- Lars
>
>
>
>________________________________
>From: Gary Helmling <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Sent: Friday, August 26, 2011 9:44 PM
>Subject: Re: RegionObserver and system tables (-ROOT-, .META.)
>
>> That led me to question: Should a RegionObserver be allowed to interfere
>> with the system tables?
>>
>>
>Yes.
>
>This is critical for the security implementation, for example.  We need to
>perform authorization checks on access to -ROOT- and .META.  If this were
>disallowed, then security couldn't be implemented on coprocessors alone.
>I'm sure there are other applications lurking out there as well.
>
>Coprocessors are very much an "experts only" feature right now.  It's
>possible to completely bork your cluster with them.  We can make them a bit
>safer to use, but going too far and neutering them only shoots ourselves in
>the foot.
>
>--gh