Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B1440173EC for ; Wed, 25 Mar 2015 01:59:59 +0000 (UTC) Received: (qmail 15663 invoked by uid 500); 25 Mar 2015 01:59:53 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 15621 invoked by uid 500); 25 Mar 2015 01:59:53 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 15609 invoked by uid 99); 25 Mar 2015 01:59:53 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Mar 2015 01:59:53 +0000 Date: Wed, 25 Mar 2015 01:59:53 +0000 (UTC) From: "Andrew Purtell (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-13294) Fix the critical ancient loopholes in security testing infrastructure. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14379134#comment-14379134 ] Andrew Purtell commented on HBASE-13294: ---------------------------------------- I noticed no branch-1.0 patch on this issue and when working one up I see that TestAccessController is using methods in SecureTestUtil that don't exist on that branch (first param is Configuration, not Connection) but those are what we want. I can add the SecureTestUtil methods but they in turn depend on AccessControlClient methods not present in branch-1.0. AccessControlClient is a Public/Evolving interface in hbase-client. _Adding_ new methods to this interface will not present a binary compatibility problem and it is tagged as Evolving. I assume there will be no issues with this but I'm making a note here now before proceeding to commit to all branches 0.98+ tomorrow morning. [~enis] > Fix the critical ancient loopholes in security testing infrastructure. > ---------------------------------------------------------------------- > > Key: HBASE-13294 > URL: https://issues.apache.org/jira/browse/HBASE-13294 > Project: HBase > Issue Type: Bug > Reporter: Srikanth Srungarapu > Assignee: Srikanth Srungarapu > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.12 > > Attachments: HBASE-13294-0.98.patch, HBASE-13294-0.98.patch, HBASE-13294-branch-1.patch, HBASE-13294.patch, HBASE-13294_v2.patch, HBASE-13294_v3.patch, HBASE-13294_v3.patch, HBASE-13294_v4.patch, HBASE-13294_v5.patch, HBASE-13294_v6.patch, HBASE-13294_v6.patch > > > Unfortunately, the "verifyDenied" method doesn't fail when action parameter returns null. The relevant code snippet > {code} > try { > Object obj = user.runAs(action); > if (requireException) { > fail("Expected exception was not thrown for user '" + user.getShortName() + "'"); > } > if (obj != null && obj instanceof List) { > List results = (List) obj; > if (results != null && !results.isEmpty()) { > fail("Unexpected results for user '" + user.getShortName() + "'"); > } > } > } > {code} > As you can see, when obj is null, it returns silently. > Fixing this issue has uncovered another major bug. While constructing actions, we're using TEST_UTIL.getConnection(), which replaces the "doAs" user with the user who initiated the connection. I really am grateful to [~mbertozzi] without whom debugging this would have been a nightmare. > Now, fixing these two issues have uncovered more issues in our tests :). The main one is we're allowing the table owner to truncate table in code. But, in test, we're not allowing him. We should either remove the code that allows owner or document that the table owner can truncate table. > The other minor issues include granting permissions to namespace, but checking whether user was able to access tables inside other namespace. > That's it, folks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)