hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <la...@apache.org>
Subject Re: On coprocessor API evolution
Date Sun, 18 May 2014 20:58:38 GMT
Coprocessors are a means to extend HBase. Nothing more, nothing less. They are not stored procedures
or triggers.
Not sure in how many other ways we can/need to phrase that.


I agree that there should be a simple way to disable user coprocessors (or at least disable
loading from HDFS) for the security conscious. Let's do that, it's simple.

There is nothing to "fix" since it ain't broken. It's only seems broken when you do not understand
what it was designed for.

You want a new API for less invasive things in a sandbox, more like stored procedures and
triggers... Sure, let's do that too. But realize that is a *new* use case, and that we'll
keep the old stuff.

-- Lars

________________________________
From: Michael Segel <michael_segel@hotmail.com>
To: dev@hbase.apache.org; lars hofhansl <larsh@apache.org> 
Sent: Sunday, May 18, 2014 10:21 AM
Subject: Re: On coprocessor API evolution


It doesn’t matter. 

Sure we can follow Vlad’s rules… but you still have to get to the root of the problem
and that is making coprocessors safe. 

Its not an easy fix, and it would mean pretty much starting from scratch. Trying to kludge
a fix is harder and will not be as good. 

Maybe you can salvage some code, but the issue is fixing coprocessors at the lowest level
and work back up. 

You have to isolate the code to one or more separate jvms so you can not only stop, but reload
the processes. 
This is more than just simple triggers but also extensibility. 

If you could pick the brains of some of the folks still under Kevin Foster (@IBM) who work
on IDS… you could get some ideas. 



On May 18, 2014, at 7:01 AM, lars hofhansl <larsh@apache.org> wrote:

> We've seen similar issues with Filters. Those are good rules to follow.
> 
> 
> 
> ________________________________
> From: Vladimir Rodionov <vladrodionov@gmail.com>
> To: "dev@hbase.apache.org" <dev@hbase.apache.org> 
> Sent: Friday, May 16, 2014 10:59 AM
> Subject: Re: On coprocessor API evolution
> 
> 
> 1) Have default implementations (abstract classes) for every interface from
> Coprocessor API.
> 2) Advise coprocessor users not to implement interface directly but sub
> class default impl.
> 3) Preserve backward compatibility by adding only new hooks/methods
> 4) DO NOT CHANGE existing API (no method renaming, method parameter type
> changes etc)
> 5) Have a regression tests to check backward compatibility.
> 
> -Vladimir
> 
> 
> 
> 
> On Fri, May 16, 2014 at 9:13 AM, Michael Segel <michael_segel@hotmail.com>wrote:
> 
>> Until you move the coprocessor out of the RS space and into its own
>> sandbox… saying security and coprocessor in the same sentence is a joke.
>> Oh wait… you were serious… :-(
>> 
>> I’d say there’s a significant rethink on coprocessors that’s required.
>> 
>> Anyone running a secure (kerberos) cluster, will want to allow system
>> coprocessors but then write a coprocessor that reject user coprocessors.
>> 
>> Just putting it out there…
>> 
>> On May 15, 2014, at 2:13 AM, Andrew Purtell <apurtell@apache.org> wrote:
>> 
>>> Because coprocessor APIs are so tightly bound with internals, if we apply
>>> suggested rules like as mentioned on HBASE-11054:
>>> 
>>>       I'd say policy should be no changes to method apis across minor
>>> versions
>>> 
>>> This will lock coprocessor based components to the limitations of the API
>>> as we encounter them. Core code does not suffer this limitation, we are
>>> otherwise free to refactor and change internal methods. For example, if
>> we
>>> apply this policy to the 0.98 branch, then we will have to abandon
>> further
>>> security feature development there and move to trunk only. This is
>> because
>>> we already are aware that coprocessor APIs as they stand are insufficient
>>> still.
>>> 
>>> Coprocessor APIs are a special class of internal method. We have had a
>>> tension between allowing freedom of movement for developing them out and
>>> providing some measure of stability for implementors for a while.
>>> 
>>> It is my belief that the way forward is something like HBASE-11125.
>> Perhaps
>>> we can take this discussion to that JIRA and have this long overdue
>>> conversation.
>>> 
>>> Regarding security features specifically, I would also like to call your
>>> attention to HBASE-11127. I think security has been an optional feature
>>> long enough, it is becoming a core requirement for the project, so should
>>> be moved into core. Sure, we can therefore sidestep any issues with
>>> coprocessor API sufficiency for hosting security features. However, in my
>>> opinion we should pursue both HBASE-11125 and HBASE-11127; the first to
>>> provide the relative stability long asked for by coprocessor API users,
>> the
>>> latter to cleanly solve emerging issues with concurrency and versioning.
>>> 
>>> 
>>> --
>>> Best regards,
>>> 
>>>    - Andy
>>> 
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>>> (via Tom White)
>> 

Mime
View raw message