我认为答案是“这就是它的工作原理”,但我想我会问,以防我做错了什么。
我帐户的默认 umask 是0077
. 我在wheel
群里。
我有一个带有此 ACL 的目录:
# file: .
# owner: root
# group: wheel
# flags: -s-
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:wheel:rwx
default:mask::rwx
default:other::r-x
我创建了一个文件,根据上面的ACL正确设置了权限。
$ touch z
$ ls -al
drwxrwsr-x+ 2 root wheel 4,096 Aug 7 12:36 .
drwxr-xr-x. 7 root root 4,096 Aug 6 17:31 ..
-rw-rw-r--+ 1 ehymowitz wheel 0 Aug 7 12:36 z
我现在决定这是一个可执行文件,所以我更改了权限。这一次,它不遵循ACL,而是遵循 umask。
$ chmod +x z
$ ls -al
drwxrwsr-x+ 2 root wheel 4,096 Aug 7 12:36 .
drwxr-xr-x. 7 root root 4,096 Aug 6 17:31 ..
-rwxrw-r--+ 1 ehymowitz wheel 0 Aug 7 12:36 z
我需要指定a+x
使这项工作。
$ chmod a+x z
$ ls -al
drwxrwsr-x+ 2 root wheel 4,096 Aug 7 12:36 .
drwxr-xr-x. 7 root root 4,096 Aug 6 17:31 ..
-rwxrwxr-x+ 1 ehymowitz wheel 0 Aug 7 12:36 z
我想我只是不明白为什么要touch
根据 ACL 创建文件,但chmod
会忽略 ACL 来调整权限。
chmod 的显式特性。
man chmod
如果您想查看有关 ACL 的一些相关想法,我发现有一个答案很有用。它使您可以查看设置文件权限的系统调用的确切详细信息。(谢谢slm!)
umask 如何影响 ACL?
但是,它不一定是如何使用这些细节的一个很好的介绍。一旦您开始想要使用默认 ACL(或传统的 set-GID),*nix 权限就会非常奇怪。目前存在一个限制,即使用 systemd 的多用户工作站操作系统不支持您想要的最一致行为的 umask (并且 udisk 使用错误的权限位安装 FAT 文件系统)。
默认 ACL 可能用于 Windows 工作站的 Unix 文件服务器。我认为在某些情况下,这可能涉及使用 hacky Samba 配置来有效地覆盖 umask。当然 Linux 可以访问 Samba,然后您可以从这个覆盖 hack^W 功能中受益。可以使用 FUSE 文件系统“bindfs”在 Linux 中配置相同的 hack。
(也就是说,
mv
同一挂载文件系统上的文件夹之间的 Linux 从不尊重不同的默认 ACL。nautilus(GNOME 文件)也不会在移动时实现默认 ACL。Windows 资源管理器会这样做)。您正在见证 Unix/Linux 权限的更微妙之处之一。当您
touch
从创建文件的父目录调用命令时,将获取 ACL。ACL 包含传统权限(模式)+ ACL。当您使用时,
chmod
您只是在操作您正在操作的文件或目录的 MODE 位。请记住,这些是离散的不同,因此在操作它们时必须小心。例子
如果你使用
strace
,你可以看到它是如何chmod
工作的。首先让我们创建一个文件file_077
:查看结果:
将文件的权限更改为
a+x
:查看生成的日志:
在这里我们可以看到它
chmod
正在询问umask
,然后相应地设置 MODE 位。它从不依赖 ACL。注意:请记住,这种询问chmod
并不是要将输出合并到umask
其操作中。