[
https://issues.apache.org/jira/browse/HBASE-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14377011#comment-14377011
]
Srikanth Srungarapu commented on HBASE-13294:
---------------------------------------------
bq. v5 is ok. It could be a bit better if the comments above the verifyX
methods are javadoc not plain comments, then we can see them from IDEs when
writing or looking over tests without having to jump back to implementation.
Not a big deal. Maybe rename 'connection' as 'systemUserConnection' ? Also not
a big deal.
Sure, I can make the changes for renaming connection and conversion to javadoc
comments.
bq.I take it the try-with-resources stuff means we won't be backporting this
change to 0.98. Or are you working up a patch for that?
I would definitely prefer to get this fixed in 0.98. Will post the patch soon.
> 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, HBASE-13294_v3.patch, HBASE-13294_v4.patch,
> HBASE-13294_v5.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)
