按路径而不是文件模式位的权限

此致

我经常发现,Unix文件处理文件权限的方法非常强大,特别是与ACL结合使用时,却很难处理。为每个创建的文件正确设置文件模式,组所有权和扩展属性很快就会变得乏味。

有没有一种方法可以用更简单的方法代替此概念(可能是每次安装),默认情况下文件从其包含的目录继承权限?

我知道这可能会违反POSIX的许多期望,但另一方面,像安静的vfat mouts这样的丁字裤已经无视模式和多项许可更改,因此不应阻止开发新的想法。

举个例子,我正在寻找一种可以确保用户将文件拖放到某个目录中的文件,并且该文件可以被给定的组写入和删除,并且只能被世界其他地方读取。 ,无论用户的umask和当前组如何。

到目前为止,我所知道的原因似乎还不够:

  • 限制性目录中的许可文件:将umask更改为0777,将目录模式更改为0770,可以在组中授予读写访问权限,并可以锁定其他用户。dir还必须设置sgid位,以便其文件获得正确的组,而不是用户的主要组。但是0777的umask可能会在不受这种限制的地方开大孔,如果人们开始使用mv来移动东西,umask并没有多大用处。
  • ACL默认值:使用setfacl可以在给定目录中为新创建的文件设置默认值。这比上面更好,但是仅适用于新创建的文件。如果人们开始四处移动文件,那么这将不起作用,并且在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力求尽可能地保持惰性,因此,如果您希望将新权限应用于已存在的文件,那么您会做一些事情setfaclchmod魔术来完成它。自动更改甚至不是可取的。您会经常听到意外打开的文件过多,或者管理员如何不考虑嵌套在更改目录下的特定目录,该目录用于已被锁定的应用程序,等等。

但是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] 删除。

编辑于
0

我来说两句

0条评论
登录后参与评论

相关文章

来自分类Dev

文件权限模式以@或+结尾

来自分类Dev

按模式读取文件

来自分类Dev

UNIX权限模式位的最后3位是什么?

来自分类Dev

UNIX权限模式位的最后3位是什么?

来自分类Dev

不是给出批处理模式的命令,而是给出 .scm 文件路径?

来自分类Dev

带按位运算符的模式

来自分类Dev

按位读取文件C ++

来自分类Dev

按路径模式排除Spring Request HandlerInterceptor

来自分类Dev

MySQL 按 URL 路径模式分组

来自分类Dev

QImage:URL而不是文件路径?

来自分类Dev

Unix文件权限取决于路径(?)

来自分类Dev

无法合并文件路径,权限被拒绝

来自分类Dev

尽管是777模式,但文件上的权限被拒绝

来自分类Dev

尽管是777模式,但文件上的权限被拒绝

来自分类Dev

如何按权限列出文件

来自分类Dev

仅更改文件权限而不是目录权限的命令

来自分类Dev

程序集32位寻址大小,而不是在64位模式下为64位

来自分类Dev

javascript sharedArrayBuffer和按位操作返回32位而不是16位数字

来自分类Dev

文件路径的XML模式数据类型

来自分类Dev

如何使用按位系统允许某些权限而不允许其他权限?

来自分类Dev

Android Studio按名称获取文件路径

来自分类Dev

使用按位运算而不是测试偶数/奇数

来自分类Dev

用按位运算符而不是逻辑比较“ if between”

来自分类Dev

如何归档文件而不是整个路径

来自分类Dev

硒文件上传URL“路径不是绝对的”

来自分类Dev

按路径模式访问 clojure.zip 树

来自分类Dev

rm按模式匹配文件名

来自分类Dev

PyCharm按模式隐藏文件

来自分类Dev

按模式计数和移动文件