GLEP 81 significantly changes the way that user management is handled,
and reveals some subtle issues in existing packages that have remained
hidden until now. Many of these issues can be avoided (in GLEP 81, but
also in general) by exercising some discipline when choosing the data
for new users and groups:
* User and group names
* Default shell
* Home directory
* Home directory ownership and permissions
This commit adds a few new sections to the "Users and Groups" chapter
that explain the current best practices, and give suggestions for
choosing the user and group data listed above. The rationale for these
choices is explained, and some notable exceptions are mentioned.
ebuild-writing/users-and-groups/text.xml | 178 +++
1 file changed, 178 insertions(+)
diff --git a/ebuild-writing/users-and-groups/text.xml
index 190a099..fca3959 100644
@@ -103,6 +103,184 @@ The defaults are the user and primary group for the
owner, and 0755 for the
+ Whenever possible, the default shell and home directory should be
+ used. The rationale for this is explained below.
+ You should embark upon a GLEP81 migration like an EAPI
+ update. Rather than simply copy your user's settings into an
+ acct-user package, you should take the opportunity to
+ re-evaluate your user's name, shell, home directory, and its
+ permissions. Our GLEP 81 implementation will reveal many user
+ management issues that were allowed to fester in the past.
+ Choosing a shell
+ In most cases, the default shell (that is, no shell) should be
+ used. Services can still be started as a user who has no shell,
+ and daemons are able to drop privileges to a user who has no
+ shell. If necessary, the administrator can override a user's
+ default shell with su -s shell
+ username. This is sufficient for testing, management
+ of SSH credentials, and for initial configuration in an ebuild's
+ pkg_config phase.
+ An obvious exception to this rule is if a human being will need
+ to log into the account interactively, as is the case with the
+ root user. Other exceptions certainly exist, but should
+ be evaluated case-by-case. In other words, if you haven't
+ checked, don't set your user's shell to /bin/bash because
+ you think he might need it.
+ The goal here is twofold. First, the principle of least
+ privilege says that if a user doesn't need a real shell, he
+ shouldn't have one. And along those same lines, not having a
+ shell gives the system administrator some peace of mind: he
+ doesn't have to be as concerned with whether or not that user
+ has a password (and how strong it is), or whether or not its
+ filesystem permissions are all set correctly, or whether or not
+ it can log in via SSH, et cetera.
+ Choosing a home directory
+ In most cases, the default home directory (that is, no home
+ directory) should be used. GLEP81 changed two aspects of user
+ management with respect to home directories:
+ Creating a user can now modify the permissions on an existing
+ directory. Should the need arise, this is necessary for a new
+ version of an acct-user package to be able to fix the
+ ownership and permissions of its home directory.
+ All user data aside from the username became non-local to
+ ebuilds that depend on that user. This is merely a side-effect
+ of moving the user creation out of the client package, and
+ into a separate acct-user package.
+ The first item means that you should be conservative when
+ choosing a home directory. If at all possible, avoid choosing a
+ home directory that is used by another package. In particular,
+ no two acct-user packages should use the same home
+ directory. At best, the ownership and permissions on a shared
+ home directory would need to be kept synchronized between all
+ packages that share it. At worst, one package goes out-of-sync
+ and introduces a security hole for the others who no longer have
+ the expected permissions.
+ The second item means that if your package requires a user, you
+ can no longer be sure of that user's home directory or its
+ ownership and permissions. If your package requires a directory
+ to be owned and writable by some user, then your package's
+ ebuild should create that directory and ensure that it is
+ writable by the user. In other words, you should not rely on the
+ directory being created "transitively" by a dependency, even if
+ that dependency is an acct-user package.