Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of yuzhihong@gmail.com designates
 74.125.82.169 as permitted sender)
MIME-Version: 1.0
Date: Tue, 1 Nov 2011 12:09:38 -0700
Message-ID: 
 <CALte62w-A9d+Xj6LHGbUDO+iFxA-p+CNNgjyga3oMezJz3f-_w@mail.gmail.com>
Subject: HBase with security build Was: An 0.92.0 Release Candidate this week?
From: Ted Yu <yuzhihong@gmail.com>
To: dev@hbase.apache.org
Content-Type: multipart/alternative; boundary=001485f1a0d6d4c37304b0b118b6

--001485f1a0d6d4c37304b0b118b6
Content-Type: text/plain; charset=ISO-8859-1

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 <ghelmling@gmail.com> 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 <stack@duboce.net> 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
> >
>

--001485f1a0d6d4c37304b0b118b6--