hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <md...@apache.org>
Subject Re: [DISCUSS] Plan to avoid backup/restore removal from 2.0
Date Mon, 13 Nov 2017 17:02:49 GMT
I know I'm late to the party here, but I've got another potential blocker
to add.

We just ran an HP fortify scan internally and the results did not look
good, specifically on IncrementalTableBackupClient and
MapReduceBackupCopyJob. I'm still sorting through whether these are
actually exploitable, or whether it's a symptom of MapReduce being an
arbitrary code execution framework anyway but this does make me wonder
about the overall security posture.

I see  "HBase Backup/Restore Phase 3: Security"[1] resolved as "Later" and
claims that it will be implemented in the client, both of which make me
uncomfortable. Security Later is a general bad practice, and it is very
rarely correct to rely on client-side security for anything.

Is there another issue that covers security? Do we rely completely on HDFS
security here for more than just the DistCP? What kind of testing has been
done with security, do we have assurances that the backups aren't
accidentally exposing tables to the world?


[1]: https://issues.apache.org/jira/browse/HBASE-14138

On Mon, Nov 13, 2017 at 10:38 AM, Josh Elser <elserj@apache.org> wrote:

> On 11/11/17 5:31 PM, Stack wrote:
>> Don't want to make any assumptions, but I hope the lack of hard objection
>>> can be interpreted as (begrudging, perhaps) acceptance of the plan. Let
>>> me/us know when possible, please!
>>> Plan seems fine.
>> Are you the owner of this feature now Josh or just shepherding it in?
> Thanks, Stack.
> Good question: should have included that out-right. Vlad, Ted, and myself
> had a chat on this last week.
> While Vlad is polishing HBASE-17852 and HBASE-17825, I told him I'll help
> out with the HBASE-18892 (testing) and the Book update. Was waiting for
> some consensus on the testing gdoc before picking that up.
> I think Vlad is still the owner, but you could certainly call me a
> shepherd. I also answer to "sherpa" ;)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message