我经常发现 Unix 处理文件权限的方式很强大，特别是与 ACL 结合使用时，但处理起来却相当困难。为每个创建的文件正确设置文件模式、组所有权和扩展属性很快就会变得乏味。
有没有什么方法可以替代这个概念（可能每个安装）更简单的是，文件默认从其包含的目录继承权限？
我知道这可能会违反许多 POSIX 期望，但另一方面，像安静的 vfat mouts 这样的东西已经忽略了模式和一些权限更改，因此这不应该阻止新想法的开发。
举个例子，我正在寻找一些东西，我可以确定，只要用户将其文件放入某个目录中，该文件就可以由给定的组写入和删除，并且只能由世界其他地方读取，无论用户的 umask 和当前组。
到目前为止我所知道的似乎还不够的原因：
- 限制性目录中的许可文件：将 umask 更改为 0777，将目录模式更改为 0770，可以在组内授予读写访问权限，并锁定世界其他部分。该目录还应该设置 sgid 位，以便其文件获得正确的组而不是用户的主要组。但是 0777 的 umask 存在在不受这种方式限制的地方打开大洞的风险，并且如果人们开始使用例如 mv 来移动东西，umask 就没有多大意义。
- ACL 默认值：使用 setfacl 可以为给定目录中新创建的文件设置默认值。这比上面的要好，但它只适用于新创建的文件。如果人们开始移动文件，这将不起作用，并且在 umask 限制过多的情况下，它也将不起作用。
答案1
是否有任何方法可以用更简单的方法替换这个概念（可能是每次安装），其中文件默认从其包含的目录继承权限？
是的，它们被称为默认 ACL：
[root@ditirlns02 acl-test]# setfacl -m d:u:jadavis6:rwx --mask .
[root@ditirlns02 acl-test]# getfacl .
# file: .
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
[root@ditirlns02 acl-test]# mkdir subDir
[root@ditirlns02 acl-test]# getfacl subDir
# file: subDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
[root@ditirlns02 acl-test]# getfacl testFile
# file: testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx #effective:rw-
group::r-x #effective:r--
mask::rw-
other::r--
[root@ditirlns02 acl-test]# getfacl subDir/testFile
# file: subDir/testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx #effective:rw-
group::r-x #effective:r--
mask::rw-
other::r--
[root@ditirlns02 acl-test]# mkdir subDir/nestedDir
[root@ditirlns02 acl-test]# getfacl subDir/nestedDir
# file: subDir/nestedDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
这是一个繁琐的示例，但它说明了默认 ACL 在创建时继承到子目录，并直接应用于（作为有效的 ACE）目录和文件。根据设计，默认 ACL 中的更改不会主动向下传递。 Unix 力求尽可能保持惰性，因此期望的是，如果您希望将新权限应用于已存在的文件，那么您将执行一些操作setfacl或chmod魔术来完成它。自动更改甚至是不可取的。您会经常听到有关文件意外地过于打开的情况，或者管理员如何没有考虑嵌套在已更改目录下的特定目录，该目录用于现在被锁定的应用程序等。
但是 0777 的 umask 存在在不受这种方式限制的地方打开大孔的风险
嗯，这与您的第一点并没有真正的关系，但是 POSIX ACL 也处理了这个问题。就许可性而言，ACL 掩码胜过用户 shell 中的 umask 设置（实际上，它们是协同工作的，因为 ACL 掩码会拒绝权限，而 umask 不会授予权限，从而导致隐式拒绝）。您可以使用以下命令修改它setfacl：
[root@ditirlns02 acl-test]# setfacl -m m:r-x testFile
[root@ditirlns02 acl-test]# getfacl testFile
# file: testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx #effective:r-x
group::r-x
mask::r-x
other::r--
正如您所看到的，即使我个人帐户上的基本 DAC 将我置于“rwx”，我的帐户仍然只能获得“rx”，因为 ACL 掩码阻止了这种情况的发生。您还可以像管理其他默认 ACL 条目一样管理默认 ACL 掩码：
[root@ditirlns02 acl-test]# getfacl afterMask
# file: afterMask
# owner: root
# group: root
user::rwx
user:jadavis6:rwx #effective:r-x
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:user:jadavis6:rwx #effective:r-x
default:group::r-x
default:mask::r-x
default:other::r-x
[root@ditirlns02 acl-test]# getfacl subDir
# file: subDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
我回到之前的目录，这样你就可以看到“无自动重新计算”的作用。
Again this won't work if people start moving files around
我有点超前了，所以我已经解释了为什么这不是理想的行为，但我可以详细说明。基本上，如果您更改默认 ACL，您几乎总是希望更改已存在的 ACL。问题在于您无法设计一个系统来正确预测权限应该是什么。如果你这样做，你就会面临其他安全和稳定问题。
例如：
您有一个文件夹，
/srv/applicationX/shares/accounting/deftManeuver其中保存有关您的公司在各个市场的业绩的专有信息，只有某些人才能访问它。/srv/applicationX/shares 通过 samba 或 NFS 共享，并在公司范围内使用。
一个新的部门启动，不同的组成员身份要求您在共享目录上为他们提供 rwx。
新部门现在可以访问专有信息。更糟糕的是，您甚至没有意识到权限是这样设置的，因为自从您不得不执行任何操作以来已经一年了，
deftManeuver所以您甚至忘记了它的存在。
这是一个有点极端的例子，但它说明了问题。如果让权限保持不动，平台至少可以说“好吧，这些权限用过的是可以接受的，所以也许他们仍然非常接近他们想要做的事情。”而在 Windows 世界中，您有权更改对您甚至不知道存在的文件的访问控制。
这样，你就可以deftManeuver对once设置适当的限制，如果你需要打开它，那么平台强迫你明确告诉它“我想要xyz在目录abc及其后代上”平台至少可以对冲它的打赌你不会做递归 setfacl 。
在我的工作生活中，这个功能曾多次拯救过我。我打开目录太多而无法解决问题，安全人员告诉我“嘿嘿嘿，不，不要这样做”，并且在过渡期间，仅新的文件的权限不安全，而不是几年/几十年积累的累积信息。
编辑（可选 ACL 咆哮）：
这并不是说 POSIX ACL 不存在实际问题，只是这里列出的反对意见要么是在模型内处理的，要么是功能而不是缺陷。
常规 POSIX ACL 的问题在于表达能力。您仍然只能获得 rwx，但应该有针对性地执行更多操作。 Windows/NTFS 对权限采取了一种猎枪式的方法，包括一些没有意义的东西（比如没有掩码的本机概念、每个用户的删除权限，而不是像 Unix 那样“如果文件名是一个文件名，那么保留文件名是没有意义的”）。空文件，因此将其折叠为“写入”或附加权限等），但包含许多确实有意义的内容，例如有权附加、更改权限的权利、获取所有权的权利等。
还有一些小问题，例如无法为每个用户或（更好）每个组设置掩码：
[root@ditirlns02 acl-test]# setfacl -m m:g:testGroup:rwx .
setfacl: Option -m: Invalid argument near character 3
[root@ditirlns02 acl-test]#
因此，没有办法明确允许某些有效权限超过掩码（一般规则并不总是如此，这迫使人们在不同用户之间的冗长解决方案或设置过于宽松的掩码之间做出决定。猜猜哪条路线通常被采取...）
老实说我不认为任何人以全面、富有表现力和安全的方式进行权限处理。
答案2
您也许可以通过滥用来实现类似的目标应用装甲。然而问题是这是否是一个好主意 - 一般来说，权限应该与数据，而不是使用存储区域，因为否则具有访问权限的用户只需通过移动文件即可将权限提升给任何人。
尽管有人可能会争辩说，即使只是读取访问权限也允许他们复制数据，您想要的解决方案给出修改那些不应该拥有这些权利的人（例如改变最新汽车发动机蓝图的秘书）。