为什么FreeBSD丢失了w掩码,但Debian保留了它?


10

我试图了解FreeBSD ACL和Linux ACL在行为上的差异。特别是默认ACL的继承机制。

我在Debian 9.6和FreeBSD 12上都使用了以下命令:

$ cat test_acl.sh
#!/bin/sh

set -xe

mkdir storage
setfacl -d -m u::rwx,g::rwx,o::-,m::rwx storage

touch outside
cd storage
touch inside
cd ..

ls -ld outside storage storage/inside

getfacl -d storage
getfacl storage
getfacl outside
getfacl storage/inside

umask

我从Debian 9.6获得以下输出:

$ ./test_acl.sh
+ mkdir storage
+ setfacl -d -m u::rwx,g::rwx,o::-,m::rwx storage
+ touch outside
+ cd storage
+ touch inside
+ cd ..
+ ls -ld outside storage storage/inside
-rw-r--r--  1 aaa aaa    0 Dec 28 11:16 outside
drwxr-xr-x+ 2 aaa aaa 4096 Dec 28 11:16 storage
-rw-rw----+ 1 aaa aaa    0 Dec 28 11:16 storage/inside

+ getfacl -d storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::rwx
mask::rwx
other::---

+ getfacl storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::---

+ getfacl outside
# file: outside
# owner: aaa
# group: aaa
user::rw-
group::r--
other::r--

+ getfacl storage/inside
# file: storage/inside
# owner: aaa
# group: aaa
user::rw-
group::rwx          #effective:rw-
mask::rw-
other::---

+ umask
0022

注意outsideinside文件具有不同的权限。特别是,该outside文件具有-rw-r--r--,这是该用户的默认值,而该inside文件具有-rw-rw----,这要尊重我分配给该storage目录的默认ACL 。

FreeBSD 12上相同脚本的输出:

$ ./test_acl.sh
+ mkdir storage
+ setfacl -d -m u::rwx,g::rwx,o::-,m::rwx storage
+ touch outside
+ cd storage
+ touch inside
+ cd ..
+ ls -ld outside storage storage/inside
-rw-r--r--  1 aaa  aaa    0 Dec 28 03:16 outside
drwxr-xr-x  2 aaa  aaa  512 Dec 28 03:16 storage
-rw-r-----+ 1 aaa  aaa    0 Dec 28 03:16 storage/inside

+ getfacl -d storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::rwx
mask::rwx
other::---

+ getfacl storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::r-x
other::r-x

+ getfacl outside
# file: outside
# owner: aaa
# group: aaa
user::rw-
group::r--
other::r--

+ getfacl storage/inside
# file: storage/inside
# owner: aaa
# group: aaa
user::rw-
group::rwx      # effective: r--
mask::r--
other::---

+ umask
0022

(请注意,getfacl即使不使用-dFreeBSD不使用where的地方,Debian 也会显示默认的ACL ,但我认为实际的ACL storage并不相同。)

在这里,outsideinside文件也具有不同的权限,但是inside文件没有Debian版本具有的组写权限,这可能是因为Debian中的掩码保留了,w而FreeBSD中的掩码丢失了w

为什么FreeBSD丢掉了w面具,但Debian保留了它?


1
getfacl storage两个系统都显示什么?
Mikel

如果您不使用粘性组位(g+s),这是否同样起作用?
sebasth

@Mikel我已经更新了原始问题内容以显示getfacl信息。
罗西(Roxy)

@sebasth我已经更新了原始问题,以删除setgid位。没关系
罗西(Roxy)

将ACL设置为后storagels 应该显示+,类似地,我希望getfacl输出与您在Debian系统上获得的输出相似。有没有setfacl回报成功退出代码?
sebasth

Answers:


1

简而言之,我想(假设)他们使用umask的方式有所不同。

0022恰好是组其他未设置的W。您可以更改umask除去写禁止并检查结果。

引用Solaris aka SunOS手册(以及注释),因为这似乎很相关:“…如果目录包含默认ACL条目,则不会应用umask(1)。…”


1
是对的又是错的吗?有没有应该遵守的标准?
罗西

我不是这方面的专家,但(具有讽刺意味的是)FreeBSD的WEB管理员有一个“规范”(可以说)实现(SunOS)条目,其中明确指出不应计入umask:freebsd.org/cgi/man.cgi?query= setfacl&manpath = SunOS + 5.10
poige

“…如果目录包含默认的ACL条目,则不会应用umask(1)。…”
poige

FreeBSD自己的手册页没有提到umask,因此这似乎是一个定义不足的行为。FreeBSD的ACL实现是否应该与SunOS相同?
罗克西

显然,它不是(提)到的原因,否则可以清楚地看出陈述和完成的事情之间存在矛盾。
poige '18年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.