hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Collins (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-7172) SecureIO should not check owner on non-secure clusters that have no native support
Date Fri, 22 Apr 2011 04:39:05 GMT

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

Eli Collins commented on HADOOP-7172:

bq. 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.

Nice, I agree. Doesn't it make sense for createForWrite to get the same treatment?

I found my brain wanting to rewrite the code as follows, feel free to ignore if you think
this is less clear.

if (shouldBeSecure) {
  return forceSecureOpenForRead(f, expectedOwner, expectedGroup);
return new FileInputStream(f);

> 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, 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