[
https://issues.apache.org/jira/browse/HDFS-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13898841#comment-13898841
]
Chris Nauroth commented on HDFS-5923:
-------------------------------------
This patch looks mostly good. Thanks, Haohui.
I see the edit log serialization format now adds a flag at the end of
{{OP_ADD}} and {{OP_MKDIR}} to indicate the presence of ACLs, since there is no
longer an ACL bit to act as the flag. Then, in HDFS-5933 this flag gets
converted to a count of the ACL entries as part of the optimization work. When
loading an old edit log (pre-ACLs), the flag/count will not be present for
existing instances of {{OP_ADD}} and {{OP_MKDIR}}, so I expect we'd fail to
read. Can we change this logic to consider layout version?
> Do not persist the ACL bit in the FsPermission
> ----------------------------------------------
>
> Key: HDFS-5923
> URL: https://issues.apache.org/jira/browse/HDFS-5923
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: hdfs-client, namenode, security
> Affects Versions: HDFS ACLs (HDFS-4685)
> Reporter: Haohui Mai
> Assignee: Haohui Mai
> Attachments: HDFS-5923.000.patch, HDFS-5923.001.patch,
> HDFS-5923.002.patch
>
>
> The current implementation persists and ACL bit in FSImage and editlogs.
> Moreover, the security decisions also depend on whether the bit is set.
> The problem here is that we have to maintain the implicit invariant, which is
> the ACL bit is set if and only if the the inode has AclFeature. The invariant
> has to be maintained everywhere otherwise it can lead to a security
> vulnerability. In the worst case, an attacker can toggle the bit and bypass
> the ACL checks.
> The jira proposes to treat the ACL bit as a transient bit. The bit should not
> be persisted onto the disk, neither it should affect any security decisions.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
