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
