[ https://issues.apache.org/jira/browse/HBASE-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Purtell updated HBASE-13294: ----------------------------------- Attachment: HBASE-13294-branch-1.0.pach Here's a patch for branch-1.0 that adds the new methods to AccessControlClient, deprecating the older versions. SecureTestUtil is an un-annotated class in src/test/ of hbase-server so I just made changes there directly. > 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.0.pach, 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)