* [gentoo-dev] [PATCH 0/1] devmanual: GLEP 81 user data guidelines
@ 2019-09-01 17:48 Michael Orlitzky
2019-09-01 17:48 ` [gentoo-dev] [PATCH 1/1] ebuild-writing/users-and-groups: " Michael Orlitzky
0 siblings, 1 reply; 4+ messages in thread
From: Michael Orlitzky @ 2019-09-01 17:48 UTC (permalink / raw
To: gentoo-dev
Now that GLEP81 is in the devmanual, this is a rough draft of the
guidelines from my earlier message. Please send me your comments,
suggestions, and complaints now so that I can address them before
posting the final draft on bugzilla.
Michael Orlitzky (1):
ebuild-writing/users-and-groups: GLEP 81 user data guidelines.
ebuild-writing/users-and-groups/text.xml | 178 +++++++++++++++++++++++
1 file changed, 178 insertions(+)
--
2.21.0
^ permalink raw reply [flat|nested] 4+ messages in thread
* [gentoo-dev] [PATCH 1/1] ebuild-writing/users-and-groups: GLEP 81 user data guidelines.
2019-09-01 17:48 [gentoo-dev] [PATCH 0/1] devmanual: GLEP 81 user data guidelines Michael Orlitzky
@ 2019-09-01 17:48 ` Michael Orlitzky
2019-09-02 16:32 ` Mike Gilbert
0 siblings, 1 reply; 4+ messages in thread
From: Michael Orlitzky @ 2019-09-01 17:48 UTC (permalink / raw
To: gentoo-dev
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 b/ebuild-writing/users-and-groups/text.xml
index 190a099..fca3959 100644
--- a/ebuild-writing/users-and-groups/text.xml
+++ b/ebuild-writing/users-and-groups/text.xml
@@ -103,6 +103,184 @@ The defaults are the user and primary group for the owner, and 0755 for the
permissions.
</p>
+<important>
+ Whenever possible, the default shell and home directory should be
+ used. The rationale for this is explained below.
+</important>
+
+<p>
+ You should embark upon a GLEP81 migration like an EAPI
+ update. Rather than simply copy your user's settings into an
+ <c>acct-user</c> 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.
+</p>
+
+<subsection>
+ <title>Choosing a shell</title>
+ <body>
+ <p>
+ 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 <c>su -s <shell>
+ <username></c>. This is sufficient for testing, management
+ of SSH credentials, and for initial configuration in an ebuild's
+ <c>pkg_config</c> phase.
+ </p>
+ <p>
+ 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
+ <c>root</c> 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 <c>/bin/bash</c> because
+ you think he <e>might</e> need it.
+ </p>
+ <p>
+ 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.
+ </p>
+ </body>
+</subsection>
+<subsection>
+ <title>Choosing a home directory</title>
+ <body>
+ <p>
+ 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:
+ </p>
+
+ <ol>
+ <li>
+ 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 <c>acct-user</c> package to be able to fix the
+ ownership and permissions of its home directory.
+ </li>
+ <li>
+ 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 <c>acct-user</c> package.
+ </li>
+ </ol>
+
+ <p>
+ 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 <c>acct-user</c> 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.
+ </p>
+
+ <p>
+ 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 <c>acct-user</c> package.
+ </p>
+
+ <p>
+ In summary,
+ </p>
+ <ul>
+ <li>
+ Avoid using an <c>ACCT_USER_HOME</c> that belongs to another
+ package.
+ </li>
+ <li>
+ No two acct-user packages should define the same
+ <c>ACCT_USER_HOME</c>.
+ </li>
+
+ <li>
+ If for example your package's configuration needs
+ <username> to be able to write to
+ <c>/var/lib/<username></c>, then your package's ebuild
+ should create that directory and set its ownership and
+ permissions. Barring any other considerations, the
+ corresponding <c>acct-user</c> package should leave
+ <c>ACCT_USER_HOME</c> at its default (empty) value; setting
+ <c>ACCT_USER_HOME=/var/lib/<username></c> creates
+ unnecessary duplication and risks desynchronizing the
+ permissions.
+ </li>
+ </ul>
+ </body>
+</subsection>
+
+<subsection>
+ <title>Choosing home directory ownership</title>
+ <body>
+ <p>
+ In most cases, the default home directory ownership is correct.
+ If a non-default home directory is needed at all, then it should
+ be writable by its user and giving ownership of it to someone
+ else would prevent that. Being unwritable indicates that a
+ shared and potentially sensitive location was chosen. Moreover,
+ the fact that the home directory is not writable suggests that
+ the default home directory (which is also not writable) would
+ suffice instead; the home directory guidelines explain why the
+ default is preferable in that case. For example, setting
+ <c>ACCT_USER_HOME_OWNER="root:root"</c> is suspicious because it
+ appears intended to "undo" the ownership changed by your user
+ package, and that would only be necessary if the path in
+ question is used by some other package.
+ </p>
+ </body>
+</subsection>
+<subsection>
+ <title>Choosing home directory permissions</title>
+ <body>
+ <p>
+ In many cases, the default home directory permissions (0755)
+ will suffice. But, if your package will work with mode 0700 or
+ 0750, then those are preferable. This is the principle of least
+ privilege again. If your package works with a non-writable home
+ directory, then you should probably be using the default of
+ <e>no</e> home directory!
+ </p>
+ <warning>
+ The world-writable bit should never be set in
+ <c>ACCT_USER_HOME_PERMS</c>. This should never be necessary, and
+ is usually exploitable.
+ </warning>
+ </body>
+</subsection>
+
+<p>
+ These suggestions are not rules and are not written in stone, except
+ perhaps for the world-writable warning. There are packages in the
+ tree that <c>chroot()</c> to <c>$HOME</c>, and require that
+ directory to be owned by <c>root:root</c> for security reasons. In
+ cases like that, it's impossible to avoid implicitly tying the user
+ to the package that needs it via the home directory, and the best you
+ can do is attempt to ensure that the users and paths are unique so
+ that no conflicts arise.
+</p>
+
+<p>
+ Unless your package is exceptional, though, following these
+ guidelines will minimize the potential for problems down the
+ road.
+</p>
</body>
</section>
--
2.21.0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] [PATCH 1/1] ebuild-writing/users-and-groups: GLEP 81 user data guidelines.
2019-09-01 17:48 ` [gentoo-dev] [PATCH 1/1] ebuild-writing/users-and-groups: " Michael Orlitzky
@ 2019-09-02 16:32 ` Mike Gilbert
2019-09-02 17:50 ` Michael Orlitzky
0 siblings, 1 reply; 4+ messages in thread
From: Mike Gilbert @ 2019-09-02 16:32 UTC (permalink / raw
To: Gentoo Dev
On Sun, Sep 1, 2019 at 1:48 PM Michael Orlitzky <mjo@gentoo.org> wrote:
> +<subsection>
> + <title>Choosing a home directory</title>
> + <body>
> + <p>
> + 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:
> + </p>
> +
> + <ol>
> + <li>
> + 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 <c>acct-user</c> package to be able to fix the
> + ownership and permissions of its home directory.
> + </li>
> + <li>
> + 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 <c>acct-user</c> package.
> + </li>
> + </ol>
> +
> + <p>
> + 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 <c>acct-user</c> 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.
> + </p>
> +
> + <p>
> + 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 <c>acct-user</c> package.
> + </p>
I can't really agree with the advice given in this section.
If I'm maintaining a package and an associated acct-user package, I'm
going to keep the two in sync. I don't see why I should have to create
a directory via pkg_postinst when I could allow the acct-user package
to do it for me.
That the data is "non-local" is irrelevant if I'm maintaining both ebuilds.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] [PATCH 1/1] ebuild-writing/users-and-groups: GLEP 81 user data guidelines.
2019-09-02 16:32 ` Mike Gilbert
@ 2019-09-02 17:50 ` Michael Orlitzky
0 siblings, 0 replies; 4+ messages in thread
From: Michael Orlitzky @ 2019-09-02 17:50 UTC (permalink / raw
To: gentoo-dev
On 9/2/19 12:32 PM, Mike Gilbert wrote:
>
> I can't really agree with the advice given in this section.
>
> If I'm maintaining a package and an associated acct-user package, I'm
> going to keep the two in sync. I don't see why I should have to create
> a directory via pkg_postinst when I could allow the acct-user package
> to do it for me.
>
> That the data is "non-local" is irrelevant if I'm maintaining both ebuilds.
>
We already have similar policies for other sorts of dependencies. If
your package links to libfoo, then libfoo goes in RDEPEND even if it
would be pulled in by some other dependency that you maintain.
Developers retire and packages change hands all the time -- having an
implicit dependency is asking for trouble, especially considering that
the explicit approach isn't much more onerous: it's one extra line. To
the next guy, the dependency won't be implicit, it will be nonexistent.
Whether you find this reasoning persuasive or not, there is at least
some precedent for it.
In the acct-user case, both methods will result in the directory being
keepdir'd. But ultimately, the point I'm trying to make in the patch is
that one method will always work while the other might not if something
outside of your control changes. Neither is more difficult, so why not
choose the way that always works, and set up the directory in the ebuild
that uses it?
User packages can be shared and home directories can change by the
design of GLEP81. You can't guarantee that no one else is going to
depend on your acct-user package, or that its home directory will never
have to change, or that you will maintain both of them forever. In any
of those situations, having the directory creation be a side effect of
enewuser is a bad idea. Why should my package create your package's
localstatedir just because I want to share a username? And why should I
have to violate the principle of least privilege, giving my user a home
directory it doesn't need? Yeah, we could address those problems when
they arise; but if they can be avoided entirely by an extra call or two
to fowners/fperms, I think it's worth doing so. Or at least worth
*suggesting* that we do so.
If any of this is more persuasive than the original, I can update the
patch. If not, I can, uh, try harder.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-09-02 17:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-09-01 17:48 [gentoo-dev] [PATCH 0/1] devmanual: GLEP 81 user data guidelines Michael Orlitzky
2019-09-01 17:48 ` [gentoo-dev] [PATCH 1/1] ebuild-writing/users-and-groups: " Michael Orlitzky
2019-09-02 16:32 ` Mike Gilbert
2019-09-02 17:50 ` Michael Orlitzky
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox