hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HADOOP-7172) SecureIO should not check owner on non-secure clusters that have no native support
Date Tue, 08 Mar 2011 18:29:59 GMT

     [ 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

View raw message