☰

扩展 ACL 并不总是被继承

tag-icon • tag-icon linux access-control-list
扩展 ACL 并不总是被继承

我有一个应用程序，它/opt/reports在 0600 处生成报告文件，其文件所有者为 root:root。为了允许外部系统自动处理这些报告，我创建了一个名为“报告”组的新服务帐户用户，将该组更改为/opt/reports报告并设置 SUIG 位，然后在/opt/reports目录上设置默认 ACL 以包含报告组 400 和掩码 400。

我注意到，当我手动创建文件时，所有权限都按预期设置，但是当应用程序创建文件时，默认值不会被继承。

[root@reports1 ~]# getfacl /opt/reports
getfacl: Removing leading '/' from absolute path names
# file: opt/reports
# owner: root
# group: report
user::rwx
group::r-x
other::r-x

[root@reports1 ~]# setfacl -R -d -n -m g:report:r,m::r /opt/reports/
[root@reports1 ~]# getfacl /opt/reports
getfacl: Removing leading '/' from absolute path names
# file: opt/reports
# owner: root
# group: report
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x              #effective:r--
default:group:report:r--
default:mask::r--
default:other::r-x

手动创建文件似乎可以正常工作

[root@reports1 ~]# echo "This is a test file" > /opt/reports/testfile.txt
[root@reports1 ~]# ls -l /opt/nessus_reports/testfile.txt
-rw-r--r--+ 1 root report 20 Apr 24 11:16 /opt/reports/testfile.txt
[root@reports1 ~]# getfacl /opt/reports/testfile.txt
getfacl: Removing leading '/' from absolute path names
# file: opt/reports/testfile.txt
# owner: root
# group: report
user::rw-
group::r-x                      #effective:r--
group:report:r--
mask::r--
other::r--

但是，当使用该应用程序生成报告时，掩码会传播到新文件

[root@reports1 ~]# ls -l /opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d
-rw-------+ 1 root report 125952 Apr 24 11:18 /opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d
[root@reports1 ~]# getfacl /opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d
getfacl: Removing leading '/' from absolute path names
# file: opt/reports/018b274b-7c21-859d-6295-1af24b14da8451d8fe886e9c192d
# owner: root
# group: report
user::rw-
group::r-x                      #effective:---
group:report:r--                #effective:---
mask::---
other::---

这是预期的行为吗？我只是误解了所涉及的术语吗？我是否错过了某个标志或选项，我是否完全从错误的方向着手？

答案1

[首先，您的 SUIG 位似乎丢失了（我预计 getfacl 输出中会出现“flags: -s-”）。然而，这并不是导致此问题的原因。]

报告生成器似乎不仅会创建具有 027 umask 的文件，而且还对文件执行显式 chmod()。执行此操作时，POSIX ACL 掩码将丢失。

尝试下列操作（以 root 身份）：

touch /opt/reports/testfile.txt
getfacl /opt/reports/testfile.txt

chmod 640 /opt/reports/testfile.txt
getfacl /opt/reports/testfile.txt

看起来明确的 chmod() 破坏了一切。

答案2

这是默认行为，因为文件在创建时具有创建它们的用户的用户：组关联。不过，仍然有希望。您只需确保在运行应用程序时，它由以报告组为主要组的用户运行。有很多关于如何做到这一点的示例。如果您查看 /etc/init.d 中的某些脚本，几乎所有脚本在启动服务时都会这样做。祝你好运！（顺便说一句，这有点表明您是 Windows 管理员，因为整个继承子对象的权限是 Windows 样式权限的默认设置，因此在文件上切换到 unix 样式 acl 的心理转换可能有点棘手。）

相关内容