[
https://issues.apache.org/jira/browse/AMBARI-8138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14278101#comment-14278101
]
Hudson commented on AMBARI-8138:
--------------------------------
SUCCESS: Integrated in Ambari-trunk-Commit #1493 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/1493/])
AMBARI-8138 AMS Collector status check reports status as stopped even though
the collector is running (jluniya) (jluniya:
http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=1441a4cdcefd75a163302eda161a32710f4abe8f)
*
ambari-server/src/main/resources/common-services/AMS/0.1.0/package/scripts/status.py
> kerberos_setup.sh chmod 0440 keytabs to hadoop group 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 specific account on only the keytabs that require being
> shared, eg:
> {code}
> chmod 0400 /etc/security/keytabs/hdfs.headless.keytab
> setfacl -m user:<additional_user>:r /etc/security/keytabs/hdfs.headless.keytab
> {code}
> Regards,
> Hari Sekhon
> http://www.linkedin.com/in/harisekhon
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
