I like the notion of HBase with security wouldn't impact HBase core.

But to make HBase with security available to wider audience, we really
should create a Jenkins build which enables security profile.
Also, it would be nice if developers outside TrendMicro can participate in
the discussion / development of security feature - as Gary pointed out
toward the end of his email.

Cheers

On Tue, Nov 1, 2011 at 12:00 PM, Gary Helmling <[EMAIL PROTECTED]> wrote:

> I'd like to lobby for the security patches (HBASE-2742 and HBASE-3025)
> going in to 0.92.  This may sound like a big change at this stage, but
> in reality the impact on current HBase core is pretty contained:
>
> * HBASE-2742 adds a "security" profile to the build, which only
> includes the security sources (security/src/...) if enabled.  The
> changes to core code in this patch mostly just enable subclassing of
> HBaseClient and HBaseServer for implementation of the SecureRpcEngine.
>
> * HBASE-3025 adds classes to the "security" source tree to implement
> authorization checking.  These break down into:
>  - an AccessController coprocessor implementation for authorization
> checking.  If not enabled, this code has no impact on core.
>  - additional shell commands for ACL manipulation: grant, revoke,
> user_permission.  These implementations check for existence of the
> security classes on the classpath and will fail gracefully with an
> error message that security is not available.
>
> The use of a maven profile means that security components will only be
> included in the build when activated (mvn ... -P security), so we can
> continue to do builds and releases without the security components, if
> needed.  To start with, we may want to do separate release packages
> for the base HBase version vs. HBase with security (0.92.0 and
> 0.92.0-security), so that only those interested in using the security
> features need be impacted by them.
>
> At Trend, we've been running a release with HBase security for the
> past 6 months in production, so it's been proven to work for us.  I
> know that there are other groups interested in working with HBase
> security on 0.92, so I would really like to find a way meet that need.
>  At the same time, all of the security components have been built to
> be optionally enabled, so I think there is very little risk to core by
> including it.
>
> --gh
>
> On Mon, Oct 31, 2011 at 11:16 AM, Stack <[EMAIL PROTECTED]> wrote:
> > There's just a few issues left.  Check it out:
> > https://issues.apache.org/jira/browse/HBASE/fixforversion/12314223
> >
> > I'm hoping we can kill these last few and post an RC this week.  If
> > there is anything you crew could do to help along the RC, I would
> > appreciate the hand (Or, if there is something you think has to make
> > it into 0.92.0, please speak up).
> >
> > Thanks all,
> > St.Ack
> >
>

> From: Ted Yu <[EMAIL PROTECTED]>

> But to make HBase with security available to wider audience, we really
> should create a Jenkins build which enables security profile.
>
> Also, it would be nice if developers outside TrendMicro can participate in
> the discussion / development of security feature - as Gary pointed out
> toward the end of his email.
+1 on both points!

Thanks Ted.

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)

>
> But to make HBase with security available to wider audience, we really
> should create a Jenkins build which enables security profile.

Completely agree.  This should be pretty easy to do by cloning the
existing build and adding "-P security".

> Also, it would be nice if developers outside TrendMicro can participate in
> the discussion / development of security feature - as Gary pointed out
> toward the end of his email.
>

Completely agree here as well.  I would love to see broader
participation in developing and evolving these features.

On Tue, Nov 1, 2011 at 1:39 PM, Gary Helmling <[EMAIL PROTECTED]> wrote:
>>
>> But to make HBase with security available to wider audience, we really
>> should create a Jenkins build which enables security profile.
>
> Completely agree.  This should be pretty easy to do by cloning the
> existing build and adding "-P security".
>

Are we talking about a tarball that has both secure and insecure hbase
or are we talking of two tarballs, insecure and secure?

St.Ack

>>
>
> Are we talking about a tarball that has both secure and insecure hbase
> or are we talking of two tarballs, insecure and secure?
>

With the current POM/profile, we would do two tarballs, insecure and secure.

The security profile adds the paths for the security classes to the
source and test-source paths:

- security/src/main/java
- security/src/test/java

So, when it's enabled, the security classes are added (as appropriate)
to hbase-xxx.jar, hbase-xxx-tests.jar, and hbase-xxx-sources.jar,
along with the existing core code.

Because of this, I think we would want to version the security builds
separately: 0.92.0 for current build, 0.92.0-security for build with
security.

What do you think?

I could see a single download with separate jars for "plain" and
"-secure" being nicer, but then that would require selecting/replacing
the jar to use.  And it would also require some additional build
engineering that may exceed my current maven skills.  My plan was to
just wait for full modularization to handle that.

--gh