hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Srikanth Srungarapu (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-13294) Fix the critical ancient loopholes in security testing infrastructure.
Date Fri, 20 Mar 2015 09:09:38 GMT

     [ 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)

Mime
View raw message