☰

为什么 openSUSE 中 useradd 的默认 umask 值设置为 022？

tag-icon • tag-icon permissions umask useradd
为什么 openSUSE 中 useradd 的默认 umask 值设置为 022？

最近用openSUSE搭建了一个非常简单的测试环境。

当我尝试配置共享目录时，没有使用ACL，但由于某种原因在该目录上使用SetGID，我注意到每个用户的默认umask设置为022（即目录上的755和文件上的644）。

这是在 中完成的/etc/login.defs。

我习惯于普通用户使用 umask 002（即 775 个目录/664 个文件），而 root 用户则使用 022。

如果我想将其设置为所有未来 useradd 的默认值，我是否应该更改上述文件中 useradd 的 umask 值？如何更改系统上所有现有用户的 umask（当然 root 帐户除外）？

答案1

umask 022（或0022）是 UNIX 系统中常用的 umask，它使用传统风格的用户帐户管理。在传统的帐户管理风格中，当创建用户时，会为用户提供一个默认组，该组可能类似于团队或部门，或者可能像“用户”一样简单。 setgid 目录（我们可以称它们为“团队目录”）无法按预期工作，因为这些文件对于其他团队成员来说是不可写的，除非用户显式地使它们可写。这不太实用，特别是当文件对用户不透明时，例如 git 存储库就是这种情况。这不被认为是一个问题，因为 ACL 为此提供了完美的解决方案。

umask 002（或0002）是 UNIX 系统中常用的 umask，它使用UPG - 用户私人组。在UPG系统中添加用户时，系统会创建一个与用户名和用户id相同的名称和组id的组。 UPG 是一种受 Debian 启发的用户帐户管理方法。正如您刚刚经历的那样，UPG 在 setgid 目录方面具有一些优势 - 只要用户不覆盖其 umask。 ACL 不会被覆盖。

最好的解决方案是重构您的用户和组帐户并启用 UPG，那么您就“安全”了。

警告！当您走捷径并简单地将 umask 更改/etc/login.defs为002(或0002) 而不是022(或0022) 时，请注意，默认情况下所有用户创建的所有文件现在都可由同一组中的所有其他用户写入。这是一个安全风险，所以这几乎肯定不是您想要的。

引入 UPG 系统的原因之一是它允许管理员配置 umask 002（或0002）而不是022（或0022），以轻松促进项目协作工作的 setgid 位，而不会出现所描述的安全风险。

据我所知，OpenSUSE 不提供在安装或 YaST 期间启用 UPG 的方法，使用 UPG 的唯一方法是纯粹使用命令行创建用户帐户，然后进行必要的更改/etc/login.defs：将其更改为具有USERGROUPS_ENAB yes.这里有一个陷阱。仅当用户 ID 和组 ID 相同时，UPG 才能正常工作。如果您对正在运行的系统进行更改，则首先必须更改现有组的 ID，这涉及将组重新分配给具有这些组的所有文件，并且在 LDAP、NFS 和 NIS 的上下文中，这可以是有点毛茸茸的。

以下是有关该主题的一些进一步阅读，当我刚接触 setgid 与 umask 和 UPG 主题时，我发现这些内容很有帮助：

答案2

回答您的主题中的问题：OpenSuSE 使用传统的 Unixumask设置，而不是其他一些 Linux 发行版采用的受 Debian 启发的设置。

编辑/etc/login.defs应该足以改变它；这不会影响当前登录的用户，也没有任何方法可以强制对当前正在运行的程序进行此类更改。它也不会影响在其~/.profile（或.bash_profile根据.login其外壳的 、 等）中覆盖它的用户。

useradd不参与此事；它是每个进程的设置，默认值是在登录期间设置的（因此login.defs而不是/etc/default/useradd）。

答案3

大多数unix系统都有一个022 umask，即默认情况下只有用户可以写入文件。

对于每个用户都位于其自己的主要组中的系统，拥有 002 umask 非常有用。然而，这个 umask 充满了危险。它会导致许多.ssh可组写目录的支持问题，因此会被 SSH 守护程序忽略。这会导致私人文件被泄露，因为它们最终属于共享组。许多文件最终属于错误的组，因此默认情况下让它们可组写并不是一个好主意。

在当时，umask 和 setgid 目录是促进用户之间共享文件的唯一方法，这有点麻烦。如今，ACL 可以做得更好：

  • 权限位与特定组相关联（而不是对一组组权限进行单独设置并选择这些权限适用的一个组）。
  • 文件的权限不需要依赖于用户可以覆盖的用户设置，它们只依赖于目录的权限。
  • 文件可以为多个组设置权限。
  • 可以在不组成组的用户之间共享文件。

Umask 已过时，请使用 ACL。

答案4

例如 RHEL 和（开放）SuSE 之间的一个区别是 RHEL 遵循用户私有组方案其中每个用户的主要组是一个与用户名同名的私有组。

(open)如果我没记错的话，SuSE将所有用户的私有组设置为“users”。

当然，如果其他用户是该组的成员，则允许用户组的成员读取所有文件的 umask 是不安全的。这就是为什么（开放）SuSE 和 RHEL 及其他系统的默认 umask 不同。

因此，在仅更改系统范围的 umask 之前，请务必检查安全隐患！

相关内容