hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9699) org.apache.hadoop.fs.FileUtil#canRead and canWrite should return false on SecurityExceptions.
Date Tue, 09 Jul 2013 01:32:47 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-9699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13702755#comment-13702755

Colin Patrick McCabe commented on HADOOP-9699:

I think Steve is right here.  If the problem is confined to the unit tests, maybe the solution
should be too.  Unless there are people running security managers in production for whom this
is a problem?

You can move the JIRA by looking under "more actions."  Please rename it too if you're going
that route.
> org.apache.hadoop.fs.FileUtil#canRead and canWrite should return false on SecurityExceptions.
> ---------------------------------------------------------------------------------------------
>                 Key: HADOOP-9699
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9699
>             Project: Hadoop Common
>          Issue Type: Bug
>            Reporter: Mark Miller
>            Priority: Minor
>         Attachments: HADOOP-9699.patch
> Currently, if a security manager denies access on these calls, a SecurityException is
thrown rather than returning false.
> This causes ugly behavior in MiniDFSCluster#createPermissionsDiagnosisString for example.
If you are running with a security manager, that method can hide root exceptions on you because
when it tries to create the permissions string, canRead and canWrite can throw security exceptions
- the original exception is lost, and the problem may not be permissions related at all (it
wasn't in the case that I ran into this).
> Rather than hardening createPermissionsDiagnosisString, it seems like these methods should
just treat SecurityExceptions as lack of access.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message