hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-7621) alfredo config should be in a file not readable by users
Date Tue, 13 Sep 2011 21:27:09 GMT

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

Aaron T. Myers commented on HADOOP-7621:

Hey Alejandro, I have a few issues with this approach:

# What's the criteria for which settings belong in which file, i.e. core-site.xml vs. security-site.xml?
The specific vulnerability which prompted this JIRA was only that {{hadoop.http.authentication.signature.secret}}
needs to be kept secret from users, yet you put all of the Hadoop Auth filter settings in
this file.
# I don't think {{0600}} are the permissions we should be using. Since the MR and HDFS daemons
are usually run as separate users, and this secret needs to be available to both, the file
should probably be {{0640}}, and have a group which is shared by both user accounts.
# I think we're asking for trouble by including this secret-containing file in the same directory
as the other, public configuration files. {{security-site.xml}} is somewhat different from
the {{taskcontroller.cfg}} file in that the latter just can't be writable by users on the
cluster boxes, whereas the former must not be readable by any user anywhere. I can virtually
guarantee that some unknowing admin will copy the whole contents of {{/etc/hadoop/conf/}}
on some cluster box to create a user's {{HADOOP_CONF_DIR}}, and in so doing accidentally expose
the secret. For that matter, those sites which share a {{HADOOP_CONF_DIR}} over NFS will have
to do something different to make sure that everything *but* {{security-site.xml}} gets shared.
# It seems like somewhere in the code (probably right before adding {{security-site.xml}}
as a resource) we should check that the file doesn't have overly-permissive permissions, much
as the {{task-controller}} binary currently does.

For all these reasons I think it makes the most sense to scrap {{security-site.xml}} entirely,
and change the setting "{{hadoop.http.authentication.signature.secret}}" to "{{hadoop.http.authentication.signature.secret.file}}",
which would be configured to point to a file whose contents are then interpreted in their
entirety as the secret for generating/validating tokens.


> alfredo config should be in a file not readable by users
> --------------------------------------------------------
>                 Key: HADOOP-7621
>                 URL: https://issues.apache.org/jira/browse/HADOOP-7621
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: security
>    Affects Versions:, 0.23.0, 0.24.0
>            Reporter: Alejandro Abdelnur
>            Assignee: Alejandro Abdelnur
>            Priority: Critical
>             Fix For:, 0.23.0, 0.24.0
>         Attachments: HADOOP-7621.patch
> [thxs ATM for point this one out]
> Alfredo configuration currently is stored in the core-site.xml file, this file is readable
by users (it must be as Configuration defaults must be loaded).
> One of Alfredo config values is a secret which is used by all nodes to sign/verify the
authentication cookie.
> A user could get hold of this secret and forge authentication cookies for other users.
> Because of this the Alfredo configuration, should be move to a user non-readable file.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message