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 22:01:09 GMT

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

Aaron T. Myers commented on HADOOP-7621:
----------------------------------------

bq. keep all auth config in one place

Sure, but it's called "{{security-site.xml}}", but it doesn't contain most of the Hadoop security
configs, just the HTTP auth filter configs. For that matter, is it unreasonable that there
might be some HTTP auth filter config which clients might need to know? It seems like we're
unnecessarily overloading the purpose of this file to be both secret and to group like-configs
in the same place.

bq. make sense. Do we have such group today?

The answer to that is going to be specific to whatever method a user uses to install/configure
Hadoop. FWIW, in CDH's packages there is a 'hadoop' group which both 'mapred' and 'hdfs' belong
to. I don't know for sure, but I bet this is what the built-in Hadoop packages do, too.

bq. so where would be the location of this 'secret' file?

Good question. Kerberos has two distinct files: {{/etc/krb5.conf}} and {{/etc/krb5kdc/kdc.conf}},
where the former is world-readable, and the latter is not. Maybe, then, {{/etc/hadoop/conf/}}
and {{/etc/hadoop/conf-secret/}} ?

bq. AFAIK you can set permissions with File but you cannot check them.

Ah, that could very well be. Pretty sure Hadoop has some classes with helper methods to deal
with getting/setting group permissions, which might use JNI or fork a sub-process.

bq. using a 'secret' file just for this secret, what if there is something else needing a
secret? we don't want those 'secrets' files to proliferate.

That's totally valid, and a very good point. Still, though, I'm not sure that the solution
you have here is appropriate. For example, what if something should be secret only to the
MR daemons, but not to the HDFS daemons, or vice versa? We couldn't reasonably put such a
secret in {{security-site.xml}}, since as previously-mentioned this file must be readable
by both.

> 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.20.205.0, 0.23.0, 0.24.0
>            Reporter: Alejandro Abdelnur
>            Assignee: Alejandro Abdelnur
>            Priority: Critical
>             Fix For: 0.20.205.0, 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

        

Mime
View raw message