用户和组
创建用户和组受 GLEP 81 约束。它通过 acct-user 和 acct-group eclass 实现。新的用户和组分别在 acct-user 和 acct-group 类别中创建为软件包。
首先，检查 UID/GID 分配列表 并选择 101 到 749 之间范围内的可用 UID/GID。如果您正在添加具有相同名称的用户和组，请分别为其 UID 和 GID 使用相同的数字。如有疑问，请从 101 开始向上选择下一个可用数字。data/api.git 存储库中提供的辅助脚本 ./bin/used_free_uidgids.sh 可用于查找下一个可用的 UID 或 GID。
将您的新用户和组添加到位于 data/api.git 存储库中的 uid-gid.txt 文件中，并在添加实际软件包之前推送它们。这算作保留标识符，并将防止冲突。之后，您可以推送新的 ebuild。
直接使用 user.eclass 的传统方法现已弃用，不得用于新的软件包。
组 ebuild
组 ebuild 位于 acct-group 类别中，软件包名称与组名称匹配。以下 acct-group/suricata 的 ebuild 可用作编写组 ebuild 的模板
# Copyright 2019-2021 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 EAPI=7 inherit acct-group DESCRIPTION="Group for Suricata IDS" ACCT_GROUP_ID=477
ACCT_GROUP_ID 必须设置为请求的 GID。
用户 ebuild
用户 ebuild 位于 acct-user 类别中，软件包名称与用户名匹配。以下 acct-user/suricata 的 ebuild 可用作编写用户 ebuild 的模板
# Copyright 2019-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
EAPI=7
inherit acct-user
DESCRIPTION="User for Suricata IDS"
ACCT_USER_ID=477
ACCT_USER_GROUPS=( ${PN} )
acct-user_add_deps
ACCT_USER_ID 必须设置为请求的 GID。 ACCT_USER_GROUPS 应列出用户所属的所有组，首先生成组。所有其他键都是可选的。
ACCT_USER_SHELL 可用于设置用户的 shell。如果未设置，则使用最接近 nologin 的系统等效项。 ACCT_USER_HOME 指定主目录，默认值为 /dev/null。 ACCT_USER_HOME_OWNER 可用于覆盖主目录的所有权，而 ACCT_USER_HOME_PERMS 可用于覆盖默认权限。默认情况下，所有者为用户和主组，权限为 0755。
您应该像 EAPI 更新一样开始 GLEP81 迁移。与其简单地将用户的设置复制到 acct-user 软件包中，不如借此机会重新评估用户的名称、shell、主目录及其权限。我们的 GLEP 81 实现将揭示过去允许长期存在的许多用户管理问题。
选择 shell
在大多数情况下，应使用默认 shell（即无 shell）。服务仍然可以作为没有 shell 的用户启动，守护进程能够将权限降低到没有 shell 的用户。如有必要，管理员可以使用 su -s <shell> <username> 覆盖用户的默认 shell。这足以用于测试、SSH 凭据管理以及 ebuild 的 pkg_config 阶段的初始配置。
此规则的一个明显例外是，如果人类需要交互式登录到帐户，例如 root 用户。当然还存在其他例外情况，但应逐一评估。换句话说，如果您没有检查，请不要将用户的 shell 设置为 /bin/bash，因为您认为他可能需要它。
此处的目标有两个。首先，最小权限原则指出，如果用户不需要真正的 shell，则不应拥有它。并且沿着同样的思路，没有 shell 可以让系统管理员高枕无忧：他无需担心该用户是否拥有密码（以及密码强度），或者其文件系统权限是否都设置正确，或者它是否可以通过 SSH 登录等。
选择主目录
在大多数情况下，应使用默认主目录（即无主目录）。GLEP81 更改了用户管理中关于主目录的两个方面
- 创建用户现在可以修改现有目录上的权限。如果需要，这对于新版本的
acct-user软件包能够修复其主目录的所有权和权限是必要的。 - 除了用户名之外的所有用户数据都对依赖该用户的 ebuild 不再是本地的。这仅仅是将用户创建从客户端软件包移到单独的
acct-user软件包中的副作用。
第一项意味着在选择主目录时应保持谨慎。如果可能，请避免选择其他软件包使用的主目录。特别是，没有两个 acct-user 软件包应该使用相同的主目录。在最好的情况下，需要在共享主目录的所有软件包之间保持所有权和权限的同步。在最坏的情况下，一个软件包不同步并为其他不再具有预期权限的软件包引入安全漏洞。
第二项意味着，如果您的软件包需要用户，您将无法确定该用户的主目录及其所有权和权限。如果您的软件包需要某个用户拥有并可写某个目录，则您的软件包的 ebuild 应创建该目录并确保用户可以写入该目录。换句话说，您不应依赖于由依赖项“传递”创建的目录，即使该依赖项是 acct-user 软件包。
总而言之，
- 避免使用属于其他软件包的
ACCT_USER_HOME。 - 没有两个 acct-user 软件包应定义相同的
ACCT_USER_HOME。 - 例如，如果您的软件包的配置需要 <username> 能够写入
/var/lib/<username>，则您的软件包的 ebuild 应创建该目录并设置其所有权和权限。除了其他考虑因素外，相应的acct-user软件包应将其ACCT_USER_HOME保留为默认值（空值）；设置ACCT_USER_HOME=/var/lib/<username>会创建不必要的重复并存在权限不同步的风险。
选择主目录所有权
在大多数情况下，默认的主目录所有权是正确的。如果根本需要非默认主目录，则它应该由其用户可写，并且将其所有权授予其他人将阻止这种情况。不可写表示选择了共享且可能敏感的位置。此外，主目录不可写的事实表明，默认的主目录（它也不可写）将足够；在这种情况下，主目录指南解释了为什么默认值更可取。例如，设置 ACCT_USER_HOME_OWNER="root:root" 值得怀疑，因为它似乎旨在“撤消”用户软件包更改的所有权，而这只有在相关路径被其他软件包使用时才需要。