[
https://issues.apache.org/jira/browse/HBASE-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Srikanth Srungarapu updated HBASE-13294:
----------------------------------------
Attachment: HBASE-13294_v3.patch
Looking at the test failures related to ACL cell tags, verifyDenied is expected
to handle null. This is a bit misleading because javadoc for AccessTestAction
says that verifyAllowed should handle null.
{code}
/**
* An AccessTestAction performs an action that will be examined to confirm
* the results conform to expected access rights.
* <p>
* To indicate an action was allowed, return null or a non empty list of
* KeyValues.
* <p>
* To indicate the action was not allowed, either throw an
AccessDeniedException
* or return an empty list of KeyValues.
*/
{code}
So, instead I created verifyIfNull and replaced verifyDenied with it. The
semantics for verifyXXXX methods are as follows.
* verifyAllowed -> passes only in case of null or non-empty list
* verifyDenied -> passes only in case of ADE.
* verifyIfNull -> passes in case of null or ADE.
* verifyIfEmptyList -> passes in case of emtpy list or ADE.
> 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
> Attachments: HBASE-13294.patch, HBASE-13294_v2.patch,
> HBASE-13294_v3.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)
