[
https://issues.apache.org/jira/browse/HADOOP-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Lipcon updated HADOOP-7172:
--------------------------------
Attachment: hadoop-7172.txt
After sleeping on this, I had second thoughts about the original way I did the
patch. It doesn't seem good to me that, on an insecure cluster, we have
different semantics based on whether the native libraries are available. So,
I've changed the condition such that the check is always skipped when security
is disabled, regardless of presence of the native libs.
Updated the JavaDoc to indicate that the security check is only done when
security is enabled.
> SecureIO should not check owner on non-secure clusters that have no native
> support
> ----------------------------------------------------------------------------------
>
> Key: HADOOP-7172
> URL: https://issues.apache.org/jira/browse/HADOOP-7172
> Project: Hadoop Common
> Issue Type: Bug
> Components: io, security
> Affects Versions: 0.22.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Critical
> Fix For: 0.22.0
>
> Attachments: hadoop-7172.txt, hadoop-7172.txt
>
>
> The SecureIOUtils.openForRead function currently uses a racy stat/open combo
> if security is disabled and the native libraries are not available. This ends
> up shelling out to "ls -ld" which is very very slow. We've seen this cause
> significant performance regressions on clusters that match this profile.
> Since the racy permissions check doesn't buy us any security anyway, we
> should just fall back to a normal "open" without any stat() at all, if we
> can't use the native support to do it efficiently.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
