Apache Hadoop — 在一个 Pod 里搭起并运维 HDFS 与 YARN

只向一个团队开放财务目录，并只给另一个人只读权限

目标

把财务文件夹锁定为只有 alice 和 finance 组可用，看到 bob 被拒绝之后，再通过 ACL 只向 bob 开放读取。用默认 ACL 让这项权限延续到新文件，并测试在所有人都能写的文件夹中，用粘滞位防止别人删除自己的文件。最后总结简单认证究竟信任什么。

为什么重要

HDFS 的权限模型与 POSIX 几乎相同——每个文件和目录都有所有者、组和权限位，想查看目录内容，就需要该目录的执行（x）权限。不同之处在于谁来决定谁是谁。在默认设置（simple 认证）下，NameNode 会原样采信客户端发来的用户名。只要一行 HADOOP_USER_NAME=root，任何人都是超级用户。本实验之所以能不断切换用户来做测试，也是这个原因。所以，权限位和 ACL 是“避免误碰别人数据的围栏”，而不是安全边界。如果需要安全边界，就必须用 Kerberos 强制认证。作为围栏，权限依然重要。按团队划分文件夹，对其他团队只按需用 ACL 开放，在所有人都能用的临时文件夹里设置粘滞位，防止删除别人的文件。如果不设置默认 ACL，权限就不会延续到新生成的文件，于是就会收到“昨天还能用，今天的文件却不行”这样的咨询。

步骤

以 root 身份创建 /proj/finance，把所有者设为 alice:finance，权限设为 750。
用 HADOOP_USER_NAME=alice 把 /data/finance/q1.csv 上传到 /proj/finance/。
用 HADOOP_USER_NAME=bob 对 /proj/finance/q1.csv 执行 -cat，把错误输出保存到 /root/hdp/perm/bob_denied.txt。
以 alice 的身份给 bob 授予 ACL——在 /proj/finance 上设置 user:bob:r-x，在 /proj/finance/q1.csv 上设置 user:bob:r--。
以 bob 的身份读取 q1.csv 并统计行数，以整数写入 /root/hdp/perm/bob_lines.txt。
以 alice 的身份在 /proj/finance 上设置默认 ACL default:user:bob:r--，再把 /data/finance/q2.csv 上传到 /proj/finance/。新文件上必须延续 bob 的 ACL。
以 root 身份创建 /proj/shared，并设为 1777（粘滞位），以 alice 的身份把 /data/finance/q1.csv 上传为 /proj/shared/alice-q1.csv，然后以 bob 的身份尝试 -rm -skipTrash 删除它，把错误输出保存到 /root/hdp/perm/sticky.txt。
在 /root/hdp/perm/report.md 中写出 ## 소유자와 권한、## ACL、## 단순 인증의 한계 三个小节。第二节写入第 5 步的行数，第三节写入 HADOOP_USER_NAME 和 Kerberos。

参考

这个 Pod 中的 NameNode 以 root 运行，所以 root 是 HDFS 超级用户。清空 HADOOP_USER_NAME 就是 root。
组由 NameNode 在自己一侧的操作系统中查找用户所属的组来决定。这个 Pod 中没有 alice 和 bob 的账户，所以两人都没有组——所属组（finance）只是作为名称存在。
ACL 用 hdfs dfs -setfacl -m <항목> <경로> 设置（占位符依次为 ACL 条目与路径），用 -getfacl 确认。目录的默认 ACL（以 default: 开头）只会延续到其下新创建的文件。
常见错误：只给文件设置 ACL，却忘了目录的执行权限；以为默认 ACL 会追溯到已有文件；把粘滞位误设成 777（应为 1777）。
官方文档：HDFS Permissions Guide · FileSystem Shell — setfacl · Hadoop in Secure Mode · WebHDFS — ACL Operations

锁定团队文件夹

以 root 身份创建 HDFS 的 /proj/finance，并执行 hdfs dfs -chown alice:finance 和 hdfs dfs -chmod 750。

750 表示所有者 rwx、组 r-x、其他人 ---。修改所有者的 chown 只有超级用户才能执行——所以要用 root。

以 alice 的身份上传

用 HADOOP_USER_NAME=alice hdfs dfs -put /data/finance/q1.csv /proj/finance/ 让 alice 上传文件。

在简单认证下，一个环境变量就能切换用户。新文件的所有者是上传的用户，组则沿用上级目录的组（BSD 规则）。请用 -ls 确认。

bob 被拒绝

执行 HADOOP_USER_NAME=bob hdfs dfs -cat /proj/finance/q1.csv，并把标准错误输出保存到 /root/hdp/perm/bob_denied.txt。

拒绝消息里包含了谁（user=）、想做什么（access=）、在哪个 inode 上被拦下（inode=）。请注意，被拦下的不是文件的读取权限，而是目录的执行权限——进不去目录，就看不到里面的文件。

用 ACL 只向一个人开放

以 alice 的身份，在 /proj/finance 上设置 user:bob:r-x，在 /proj/finance/q1.csv 上设置 user:bob:r-- ACL（hdfs dfs -setfacl -m）。

权限位只能表达“所有者、组、其他人”这三类。ACL 则可以加上命名的用户和组。目录必须有执行（x）权限，才能触及其中的文件。修改 ACL 是所有者（或超级用户）的职责。

现在 bob 能读了

用 HADOOP_USER_NAME=bob 对 /proj/finance/q1.csv 执行 -cat 并统计行数，以整数写入 /root/hdp/perm/bob_lines.txt。

对带有 ACL 的文件做权限检查时，会同时看命名用户条目和 mask。-getfacl 中的 #effective: 标注才是实际生效的权限。

默认 ACL——让新文件也延续权限

以 alice 的身份在 /proj/finance 上设置 default:user:bob:r--，再用 HADOOP_USER_NAME=alice 把 /data/finance/q2.csv 上传到 /proj/finance/。新文件 q2.csv 上必须延续 user:bob:r--。

默认 ACL 只能设置在目录上，并复制到其下新创建的对象。已有的 q1.csv 不会被追溯。请用 -getfacl 观察：设置默认 ACL 之后，新文件的其他（other）权限也会遵循默认 ACL。

粘滞位——在所有人的文件夹里保护别人的文件

以 root 身份创建 /proj/shared 并用 hdfs dfs -chmod 1777 设置，再以 alice 的身份把 /data/finance/q1.csv 上传为 /proj/shared/alice-q1.csv，然后把 HADOOP_USER_NAME=bob hdfs dfs -rm -skipTrash /proj/shared/alice-q1.csv 的错误输出保存到 /root/hdp/perm/sticky.txt。

在权限为 777 的目录中，任何人都可以删除任何人的文件（因为删除取决于目录的写权限）。设置了粘滞位后，只有文件的所有者和目录的所有者才能删除。/tmp 之所以是这样设置的，原因就在这里。

把围栏和锁区分开并记录下来

在 /root/hdp/perm/report.md 中写出 ## 소유자와 권한、## ACL、## 단순 인증의 한계 三个小节。第二节写入第 5 步的行数，第三节写入 HADOOP_USER_NAME 和 Kerberos。

第三节是关键。请写出：在本实验中切换用户的方法，在生产环境中意味着什么；因此生产集群需要什么。