☰

为什么 NFSv4 不能以可用的方式转换 POSIX ACL？

tag-icon • tag-icon linux acl xfs nfsv4
为什么 NFSv4 不能以可用的方式转换 POSIX ACL？

我有一个 XFS 文件系统，其中某些文件夹（使用模式设置）没有公共可访问性，组所有者具有只读权限。有一个程序（以用户 Cryoparc_user 身份运行）需要对所有文件进行读取访问权限，因此我添加了一个默认的 POSIX ACL，授予 Cryoparc_user 读取访问权限。

不幸的是，大部分处理是在 NFSv4 安装此文件系统的工作站上完成的，并且由于某种原因，POSIX ACL 没有在工作站上被翻译或尊重（嗯，它们是，但显然不是以可用的方式），我可以不明白为什么。

服务器和工作站都运行 Ubuntu 18.04，我不能简单地将 Cryoparc_user 添加到组中，因为该组是 Active Directory 安全组（我们通过 AD 进行身份验证），而 Cryoparc_user 是本地用户，不能设立于公元。

以下是文件服务器上的权限：

root@kraken:/EM/EMtifs# getfacl pgoetz
# file: pgoetz
# owner: pgoetz
# group: cns-cnsitlabusers
user::rwx
group::r-x
other::---
default:user::rwx
default:user:cryosparc_user:r-x
default:group::r-x
default:mask::r-x
default:other::---

root@kraken:/EM/EMtifs# id cryosparc_user
uid=1017(cryosparc_user) gid=1017(cryosparc_user) groups=1017(cryosparc_user),10002(mclellan),10003(taylorlab)

以下是它们在带有 NFSv4 安装的工作站上的外观：

root@javelina:/EM/EMtifs# getfacl pgoetz
# file: pgoetz
# owner: pgoetz
# group: cns-cnsitlabusers
user::rwx
group::r-x
other::---

root@javelina:/EM/EMtifs# id cryosparc_user
uid=1017(cryosparc_user) gid=1017(cryosparc_user) groups=1017(cryosparc_user)

root@javelina:/EM/EMtifs# nfs4_getfacl pgoetz
A::OWNER@:rwaDxtTcCy
A::GROUP@:rxtcy
A::EVERYONE@:tcy
A:fdi:OWNER@:rwaDxtTcCy
A:fdi:1017:rxtcy
A:fdi:GROUP@:rxtcy
A:fdi:EVERYONE@:tcy

请注意 NFS4 ACL 查询中从底部算起的第三行。然而，cryoparc_user 用户似乎具有读取权限（两个系统上的本地 UID 均为 1017）

cryosparc_user@javelina:/EM/EMtifs$ whoami
cryosparc_user
cryosparc_user@javelina:/EM/EMtifs$ ls pgoetz
ls: cannot open directory 'pgoetz': Permission denied

从我读到的所有内容来看，没有要设置的安装标志或类似的东西；这应该会自动工作，我不明白为什么它不起作用。

我的后备计划是恢复使用这些文件夹上的本地组（以便可以将cryoparc_user 添加到本地组），但这将需要在每个系统上复制 AD 身份验证结构，这将是一个令人头痛的维护问题。

另一个想法是使用 Cryoparc_user 用户凭据来对该文件系统进行只读 SMB 挂载，但我对双重挂载 500T 文件系统也不是很兴奋。我宁愿身份验证以合理的方式工作。

答案1

我的问题是无法理解 POSIX ACL 的工作原理；特别是我假设默认ACL 在其所应用的目录上设置权限，而实际上这些权限仅适用于子目录和文件在将默认 ACL 应用于父对象后创建实际上根本不应用父对象。

引起我注意的是 NFS 开发人员列表中关于此问题的上诉。一位开发商指出（知道这一点很重要）NFS 对此完全不可知，而只是诉诸于服务器底层文件系统上设置的权限。这为我指明了查看服务器文件系统上的 POSIX ACL 的方向，并且——经过一些实验（记录很少）——我意识到了上述功能，并重新创建了 POSIX ACL 以实际执行我希望它们执行的操作。此后问题就消失了。

答案2

可能称为 POSIX ACL 的东西并不存在。

aprox 有一份标准提案草案。 1993 年，由于用户不喜欢这种 ACL 实现，该协议于 1997 年被撤销。

现有的 ACL 的唯一标准是 NFSv4。

尝试使用支持 NFSv4 ACL 的现代操作系统。

相关内容