我经常发现,Unix文件处理文件权限的方法非常强大,特别是与ACL结合使用时,却很难处理。为每个创建的文件正确设置文件模式,组所有权和扩展属性很快就会变得乏味。
有没有一种方法可以用更简单的方法代替此概念(可能是每次安装),默认情况下文件从其包含的目录继承权限?
我知道这可能会违反POSIX的许多期望,但另一方面,像安静的vfat mouts这样的丁字裤已经无视模式和多项许可更改,因此不应阻止开发新的想法。
举个例子,我正在寻找一种可以确保用户将文件拖放到某个目录中的文件,并且该文件可以被给定的组写入和删除,并且只能被世界其他地方读取。 ,无论用户的umask和当前组如何。
到目前为止,我所知道的原因似乎还不够:
有没有一种方法可以用更简单的方法代替此概念(可能是每次安装),默认情况下文件从其包含的目录继承权限?
是的,它们被称为默认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掩码胜过用户外壳程序中的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共享,并且在公司范围内使用。
成立了一个新部门,不同的组成员资格要求您在shares目录中给他们rwx权限。
现在,新部门可以访问专有信息。更糟糕的是,您甚至还没有意识到以这种方式设置权限,因为距离必须做任何事情已经有一年了,deftManeuver
所以您甚至忘了它还在那儿。
那是一个极端的例子,但是它说明了这个问题。离开权限惰性的,该平台至少可以说“很好,这些权限使用是可以接受的,所以也许他们仍然非常接近,他们正在试图做什么。” 在Windows世界中,您具有更改甚至不知道存在的文件的访问控制的权限。
这样,您可以deftManeuver
在适当的限制下设置一次,如果需要将其打开,则平台将强制您明确告诉它“我要在目录abc及其后代上使用xyz”,该平台至少可以对冲其赌你不做递归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]#
因此,没有办法明确允许某些有效权限超出掩码(一般情况下并不总是一件好事,这迫使人们在不同用户之间进行长时间的变通或在设置过于宽松的掩码之间做出决定。通常采取...)
老实说,我认为没有人以全面,富有表现力和安全的方式进行许可。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句