facl、setfacl、目录共享,为什么cp要把原来的文件权限放到facl mask里呢?这不应该是 cp -p 行为吗?

facl、setfacl、目录共享,为什么cp要把原来的文件权限放到facl mask里呢?这不应该是 cp -p 行为吗?

该系统上的用户很小心,并将其 umask 设置为非常私密的 0077。但是,用户希望拥有特定于组的目录,可以在其中复制文件,以便在其他组成员之间显式共享它们。可能有多个这样的共享目录,尽管每个目录都特定于一个组。

在给定目录上设置组粘滞位以用于共享是不够的。虽然设置粘性位使得放置在目录中的文件的组所有权是正确的,但所述文件的权限通常被设置为使得文件不能被读取或编辑,即不能实际上被共享。它们仅出现在目录列表中。这是因为某些用户要么不想,要么不知道如何手动进行所需的组权限调整以允许读取和写入。我们可以让他们休息一下,因为毕竟用户不是管理员。 访问控制列表可用于指定特定组有权访问共享目录中的文件,而与没有 acls 时该组的权限无关。这是一个完美的解决方案,但效果并不理想。

在下面,共享组是“customer_gateway”,尝试共享文件的示例用户是“svw”。从脚本中可以看出,svw 用户是 customer_gateway 组的成员。进行共享的目录也称为“customer_gateway/”

以下使用 acl。我设置了组权限、默认组权限、掩码和默认掩码。它适用于在目录中创建的文件,或者通过 cat (或 tar)移动到那里的文件,但奇怪的是,不适用于在那里“cp”的文件:

# rm -r customer_gateway/
# umask
0077
# cat ~/script1

mkdir customer_gateway
chown :customer_gateway customer_gateway/
chmod g+rwx  customer_gateway/
setfacl -m group:customer_gateway:rwX customer_gateway/
setfacl -m d:group:customer_gateway:rwX customer_gateway/
setfacl -m m::rwX customer_gateway/
setfacl -m d:m::rwX customer_gateway/
getfacl customer_gateway
cd customer_gateway
touch cga
cat << EOF > cgb
c g b
EOF
ls -l

# . ~/script1
# file: customer_gateway
# owner: root
# group: customer_gateway
user::rwx
group::rwx
group:customer_gateway:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:customer_gateway:rwx
default:mask::rwx
default:other::---

total 4
-rw-rw----+ 1 root root 0 Mar  2 20:43 cga
-rw-rw----+ 1 root root 6 Mar  2 20:43 cgb

# su - svw
/home/svw/bin:/usr/local/bin:/usr/bin:/bin

(note umask is 0077)

> cd /share/customer_gateway/
> groups
svw adm dip video plugdev google-sudoers customer_gateway
> cat >> cga
e f g
> cat > cgc
c g c
> ls -l
total 12
-rw-rw----+ 1 root         root         6 Mar  2 20:44 cga
-rw-rw----+ 1 root         root         6 Mar  2 20:43 cgb
-rw-rw----+ 1 svw svw 6 Mar  2 20:44 cgc
> ls ~/dat
ta  tb  tc
> cat ~/dat/ta > ta
> cp ~/dat/tb tb
> ls -l
total 20
-rw-rw----+ 1 root         root         6 Mar  2 20:44 cga
-rw-rw----+ 1 root         root         6 Mar  2 20:43 cgb
-rw-rw----+ 1 svw svw 6 Mar  2 20:44 cgc
-rw-rw----+ 1 svw svw 4 Mar  2 20:45 ta
-rw-------+ 1 svw svw 4 Mar  2 20:45 tb
> getfacl ta
# file: ta
# owner: svw
# group: svw
user::rw-
group::rwx          #effective:rw-
group:customer_gateway:rwx  #effective:rw-
mask::rw-
other::---
> getfacl tb
# file: tb
# owner: svw
# group: svw
user::rw-
group::rwx          #effective:---
group:customer_gateway:rwx  #effective:---
mask::---
other::---
> 

这表明,当在目录中创建文件时,它会收到默认权限并且可以共享。但用户并不总是在那里创建文件,通常他们会在那里复制文件。

但是进行复制是同样的事情,因为要进行复制,我们必须首先创建一个新文件。我们在这里讨论的是普通副本,而不是保留权限副本。它与以下形式相同,顺便说一句,它确实起作用并复制一个文件,该文件将在目录中共享,而与其原始组权限无关:

cat < data.in  > shared/data.out

工作得很好,通过焦油管道也可以工作,但是形式

cp data.in shared/data.out

失败。 edcat文件获取默认掩码和默认权限。 edcp文件在 acl 掩码和组权限中保留其权限,就好像它是 cp -p (但事实并非如此),因此有效权限的读取方式与原始文件类似,而不是 acl 设置的内容到。

作为第二次尝试,我使用组粘性位 chmod g+rwxs 以及 facl 更改来运行此实验,并得到了完全相同的结果。尽管目录列表更漂亮,因为所有共享文件都显示了组所有权。我还只设置了组粘性位,而不使用 setfacl 来运行它。对于复制的文件也有相同的结果(因此 facls 对于复制文件以进行共享的目录来说看起来相当无用)。

linux facls 区分不同形式的创建数据的依据和理由是什么?为什么在没有被告知这样做的情况下强制 cp 保留权限?有什么理由可以证明 cat 和通过 tar 工作而 cp 不工作的管道之间的区别所造成的混乱是合理的?我是否错过了一个可以让这种区别消失的魔法咒语?

此摘要是否正确:facls 将允许您克服共享文件的所有权,在“创建”文件时,它将使权限比 umask 更宽松,除非创建是由于 cp 命令并且有充分的理由,因为......因为为什么?

答案1

到目前为止,所有答案都给出了有关如何通过组目录处理共享文件的建议。我认为,Non 已经回答了您的主要问题,即:为什么cp a b行为就像cp -p a b被指定一样?这手册页确实没有谈论它,但是文本信息有详细信息。info coreutils 'cp invocation'显示:

 ‘-p’
 ‘--preserve[=ATTRIBUTE_LIST]’
 Preserve the specified attributes of the original files. ...
 
 ...

 In the absence of this option, the permissions of existing
 destination files are unchanged.  Each new file is created with the   <===
 mode of the corresponding source file minus the set-user-ID,          <===
 set-group-ID, and sticky bits as the create mode; the operating
 system then applies either the umask or a default ACL, possibly
 resulting in a more restrictive file mode.
 
 ...

因此,如果目标存在,则内容将被替换,但模式位不会改变。如果目标不存在不是存在,模式位从源复制。

答案2

创建一个用户可以进入的目录的事实非常简单并且可以轻松完成。

  • 首先,您需要找到一个合适的位置来创建此目录,我建议将其创建在所有人都可以访问的目录下(目前)。使用命令须藤 mkdir创建您的新目录。

  • 其次,您需要创建一个组,组只是用户的集合,这些用户被四舍五入以限制或访问 Linux 系统的某些部分。您在输入以下内容时可能已经看到了组ls-l命令列出如下内容:

rwxrwxrwx 3 root 管理员 4736 十月 24 12:32 File1.doc

说的部分是所有者,**admins ** 是拥有该文件的组。组确保了允许某些人查看文件的简单方法。要创建组,请键入“sudo groupadd”,这将是用于目录的组。

  • 创建组后,您可以使用以下命令将要访问目录的用户添加到其中须藤添加用户 这将允许您添加用户,您可以使用 group 命令验证该用户是否在组中。

完成此操作后,浏览到您创建的目录并将组权限设置为 7 (rwx) 请记住,您可以根据自己的喜好调整这些权限,但 7 为该组的用户提供对该目录的完全权限,您可以通过键入“sudo chmod”来执行此操作770"

接下来,您需要更改目录的组所有权,因此目录的组所有者就是您创建的组,请使用以下命令“sudo chown -R :groupname”执行此操作。

完成这一切后,您现在可以将任何人添加到该组中,只要他们位于该特定组中即可访问该目录,他们就可以复制和共享文件。如果您觉得这有帮助,请告诉我!!!!!!!

答案3

我会删除所有 acl,只使用用户和组权限。然后是chmod 777您希望每个人都可以访问的文件夹。然后测试您的访问权限。

然后chmod 770再次测试文件夹访问。

当这个工作正常时,应该一次添加一个 ACL。

如果他们不需要执行权限,您可以使用 chmod 660 文件夹名称将其降低到 rw*,rx*,***

请记住,在您没有 acl 和 chmod 777 权限的时期,您的文件夹将对所有人完全开放,因此不要像这样保留它。

答案4

我试过了。看来 umask 正在关闭组权限,因为组权限是 ACL 的掩码。它阻止了所有组和 ACL。

解决方法是减少 umask 的限制。为了安全地执行此操作,您需要为每个用户添加一个组,并将该组设置为默认组。 (看为什么每个用户都有自己的组?)。

这并不理想,因为仍然存在不同 umask 的情况(g=rx 和 g=rwx)。此策略仅消除了对无组权限的需要。

相关内容