>From the refguide patch: Only an HBase superuser (e.g. hbase) is allowed to perform backup/restore
Would the lines you mentioned pose potential concern even when run by superuser ? On Mon, Nov 13, 2017 at 11:45 AM, Mike Drob <mad...@cloudera.com> wrote: > Sure, I don't think there are any issue with sharing this publicly, since > the code has only gone out in alpha releases. > > The suspect lines in IncrementalTableBackupClient are 163 and 326. I'm > still working on validating the call path that leads to those getting > flagged. > > The issues in MapReduceBackupCopyJob are on lines 386, 405, and 407. > > All of them relate to un-sanitized inputs in one way or another. > > On Mon, Nov 13, 2017 at 12:50 PM, Ted Yu <yuzhih...@gmail.com> wrote: > > > Mike: > > Can you share your finding w.r.t. IncrementalTableBackupClient and > > MapReduceBackupCopyJob > > ? > > > > IncrementalTableBackupClient utilizes WALPlayer directly. > > > > I wonder what vulnerability there is. > > > > Thanks > > > > On Mon, Nov 13, 2017 at 9:02 AM, Mike Drob <md...@apache.org> wrote: > > > > > 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? > > > > > > Thanks, > > > Mike > > > > > > [1]: https://issues.apache.org/jira/browse/HBASE-14138 > > > > > > On Mon, Nov 13, 2017 at 10:38 AM, Josh Elser <els...@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" ;) > > > > > > > > > >
