You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Hari Sekhon (JIRA)" <ji...@apache.org> on 2014/11/04 12:33:33 UTC
[jira] [Updated] (AMBARI-8138) kerberos_setup.sh chmod 0400 keytabs
too loose should be using setfacl instead
[ https://issues.apache.org/jira/browse/AMBARI-8138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hari Sekhon updated AMBARI-8138:
--------------------------------
Description:
kerberos_setup.sh is doing chmod 0440 on the cluster's kerberos keytabs with group hadoop which would allow all the hadoop daemon user accounts to read each other's kerberos keytabs.
This is technically bad practice as a single breach in any even tertiary component will result in compromising all kerberos keytab credentials across all components and to all data via the hdfs keytab.
A better solution would be to use extended ACLs to grant permissions to a single additional user account for each keytab where required.
{code}
chmod 0400 /etc/security/keytabs/hdfs.headless.keytab
setfacl -m user:<additional_user>:r /etc/security/keytabs/hdfs.headless.keytab
{code}
to allow for instances where one daemon needs to use another's keytab.
Regards,
Hari Sekhon
http://www.linkedin.com/in/harisekhon
was:
kerberos_setup.sh is doing chmod 0440 on the cluster's kerberos keytabs with group hadoop which would allow all the hadoop daemon user accounts to read each other's kerberos keytabs.
This is technically bad practice as a single breach in any even tertiary component will result in compromising all kerberos keytab credentials across all components and to all data via the hdfs keytab.
A better solution would be to use extended ACLs to grant permissions to a single additional user account for each keytab where required.
{code}
chmod 0400 /etc/security/keytabs/hdfs.headless.keytab
setfacl -m user:<additional_user>:r /etc/security/keytabs/hdfs.headless.keytab
{code}
to allow for instances where one daemon needs to use another's keytab for some reason.
Regards,
Hari Sekhon
http://www.linkedin.com/in/harisekhon
> kerberos_setup.sh chmod 0400 keytabs too loose should be using setfacl instead
> ------------------------------------------------------------------------------
>
> Key: AMBARI-8138
> URL: https://issues.apache.org/jira/browse/AMBARI-8138
> Project: Ambari
> Issue Type: Improvement
> Environment: HDP 2.1
> Reporter: Hari Sekhon
> Priority: Minor
>
> kerberos_setup.sh is doing chmod 0440 on the cluster's kerberos keytabs with group hadoop which would allow all the hadoop daemon user accounts to read each other's kerberos keytabs.
> This is technically bad practice as a single breach in any even tertiary component will result in compromising all kerberos keytab credentials across all components and to all data via the hdfs keytab.
> A better solution would be to use extended ACLs to grant permissions to a single additional user account for each keytab where required.
> {code}
> chmod 0400 /etc/security/keytabs/hdfs.headless.keytab
> setfacl -m user:<additional_user>:r /etc/security/keytabs/hdfs.headless.keytab
> {code}
> to allow for instances where one daemon needs to use another's keytab.
> Regards,
> Hari Sekhon
> http://www.linkedin.com/in/harisekhon
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)