Re: [gentoo-dev] [PATCH 2/2] install-qa-check.d: allow acct-user home directories under /home.
On Mon, 2020-01-20 at 19:22 -0500, Michael Orlitzky wrote: > Let it die =) I'm not going to apply the patch; it's there if someone > else decides that it's the least-bad solution to this problem. > > > On 1/20/20 6:57 PM, Andreas K. Huettel wrote: > > Why *isn't* some /var/lib/... possible here? > > It is, the question is how many backflips we should be doing to avoid > putting what is practically and factually a home directory in /home. I > have a few of these packages. I will echo ulm's sentiment that it's just > awful to put them all in > > /var/lib/user1-home > /var/lib/user2-home > ... > > rather than /home/user1 and /home/user2. > > That's also second-guessing the administrator, whose home directory > policies for e.g. backups very likely apply to the home directories I'm > creating. (Keep in mind that I'm only talking about exceptions for very > special packages that install a system user that will also be used by a > human or that stores per-user configuration. And the exception is only > for the keepdir file.) > > Home directories in /home were also allowed with user.eclass, which > means that we now hit a roadblock updating those accounts to GLEP81. > Please don't conflate 'allowed' with 'nobody noticed it'. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 2/2] install-qa-check.d: allow acct-user home directories under /home.
Let it die =) I'm not going to apply the patch; it's there if someone
else decides that it's the least-bad solution to this problem.
On 1/20/20 6:57 PM, Andreas K. Huettel wrote:
>
> Why *isn't* some /var/lib/... possible here?
It is, the question is how many backflips we should be doing to avoid
putting what is practically and factually a home directory in /home. I
have a few of these packages. I will echo ulm's sentiment that it's just
awful to put them all in
/var/lib/user1-home
/var/lib/user2-home
...
rather than /home/user1 and /home/user2.
That's also second-guessing the administrator, whose home directory
policies for e.g. backups very likely apply to the home directories I'm
creating. (Keep in mind that I'm only talking about exceptions for very
special packages that install a system user that will also be used by a
human or that stores per-user configuration. And the exception is only
for the keepdir file.)
Home directories in /home were also allowed with user.eclass, which
means that we now hit a roadblock updating those accounts to GLEP81.
>
> I mean, user configuration works perfectly fine there, even if you have to
> log in. And the purpose of the account is closer to, say, root (with its
> nonstandard home directory location) than a normal user.
>
> I've seen all possible site-specific changes to /home layout, including,
> e.g.,
> * /home/server1/username
> * /home/large/username
> * /home/u/username
> ...
> which would all get somehow messy if a system account with a fixed path is
> forced in there.
>
Sure, but is having them scattered across BOTH /home AND /var/lib less
messy? We're picking a default, and with GLEP81, the people who do this
could move it to /home/u/${PN} with an overlay ebuild; whatever makes
them happy. For everyone else, it's a good default.
Re: [gentoo-dev] [PATCH 2/2] install-qa-check.d: allow acct-user home directories under /home.
Am Montag, 20. Januar 2020, 04:43:50 CET schrieb Michael Orlitzky:
> In rare cases, a system user will need a real home directory to store
> per-user configuration data and/or be accessed interactively by a
> human being. In those cases, /home/${username} is an appropriate place
> for the user's home directory. Using /home is allowed and encouraged
> by the FHS, and there are no real technical obstacles to it aside from
> an install-time QA warning about the path.
Why *isn't* some /var/lib/... possible here?
I mean, user configuration works perfectly fine there, even if you have to
log in. And the purpose of the account is closer to, say, root (with its
nonstandard home directory location) than a normal user.
I've seen all possible site-specific changes to /home layout, including,
e.g.,
* /home/server1/username
* /home/large/username
* /home/u/username
...
which would all get somehow messy if a system account with a fixed path is
forced in there.
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
Re: [gentoo-dev] [PATCH 2/2] install-qa-check.d: allow acct-user home directories under /home.
On Sun, 2020-01-19 at 22:43 -0500, Michael Orlitzky wrote:
> In rare cases, a system user will need a real home directory to store
> per-user configuration data and/or be accessed interactively by a
> human being. In those cases, /home/${username} is an appropriate place
> for the user's home directory. Using /home is allowed and encouraged
> by the FHS, and there are no real technical obstacles to it aside from
> an install-time QA warning about the path.
>
> Before GLEP81, the efficacy of this check was unarguable. With
> enewuser, you could still set a user's home directory to a location
> under /home, but the lack of a "keepdir" meant that it would fly under
> the radar during the QA check. As a result, the QA check would only
> flag truly problematic files. With GLEP81, however, an implementation
> detail leads this check to flag the user's home directory.
>
> This commit makes an exception for the home directory /home/${PN}
> itself, and the /home/${PN}/.keep* file it contains. This lets us
> migrate existing user.eclass ebuilds to GLEP81 without triggering a
> new QA warning on a dummy file.
>
> This will be useful in at least two real situations:
>
> * The "amavis" user exists to launch the amavisd daemon, but much of
> the configuration for that user is created in $HOME by a human who
> is logged in as "amavis" interactively. This is user data by any
> definition, and should be stored in /home/amavis rather than
> dumping it in the daemon's working directory.
>
> * The "spamd" user gets its SpamAssassin configuration the same way
> local users do in a traditional UNIX mail setup: by reading it out
> of $HOME. This is user data, even though it happens to affect the
> daemon. With user.eclass, /home/spamd is already used as the home
> directory. When migrating to GLEP81, we should not break existing
> systems and force a migration just to avoid an old warning.
>
> There are other potential uses as well. If I want to share (real
> human) user accounts across multiple Gentoo installs per the design of
> GLEP81, then I can do that with acct-user packages in an overlay. The
> user packages ensure that the same UIDs and GIDs get used on every
> system, but if I do this with my "mjo" account, I'm going to want
> /home/mjo to be my home directory. There's nothing wrong with that,
> so we shouldn't warn about it.
> ---
> metadata/install-qa-check.d/08gentoo-paths | 27 ++
> 1 file changed, 27 insertions(+)
>
> diff --git a/metadata/install-qa-check.d/08gentoo-paths
> b/metadata/install-qa-check.d/08gentoo-paths
> index 5161aef9922..ab9bd64d0e0 100644
> --- a/metadata/install-qa-check.d/08gentoo-paths
> +++ b/metadata/install-qa-check.d/08gentoo-paths
> @@ -19,6 +19,10 @@ gentoo_path_check() {
> boot dev etc opt srv usr var
> )
>
> + # We make an exception and allow acct-user packages to install to
> + # /home in rare circumstances.
> + [[ "${CATEGORY}" == "acct-user" ]] && allowed_paths_toplevel+=( home )
> +
> # directories in /usr which can be installed to by ebuilds
> # /usr/games is not included as it is banned nowadays
> local allowed_paths_usr=(
> @@ -61,6 +65,29 @@ gentoo_path_check() {
> fi
> done
>
> + # Normally ebuilds should not install anything under /home. If this
> + # is a GLEP81 user package, however, we make an exception for the
> + # user's home directory itself and the ".keep" file within it. This
> + # allows GLEP81 user packages to have home directories under /home,
> + # which can be useful if the account is meant to be used by a human
> + # to store configuration data or run maintenance tasks.
> + if [[ "${CATEGORY}" == "acct-user" ]]; then
> + local f found=()
> + while read -r -d '' f; do
> + found+=( "${f}" )
> + done < <(find -L "${ED%/}/home" \
> + -mindepth 1 \
> + -maxdepth 2 \
> + ! -path "${ED%/}/home/${PN}" \
> + ! -path "${ED%/}/home/${PN}/.keep*" \
> + -print0)
> +
> + if [[ ${found[@]} ]]; then
> + # mimic the output for non-acct-user packages.
> + bad_paths+=( "/home" )
> + fi
> + fi
> +
> ${shopt_save}
>
> # report
NAK. /home belongs to paths that are deliberately left for sysadmin to
manage and use for real (read: human) users. 'Rare cases' are no
justification to abuse those paths, especially that there is no
technical reason not to use /var (or /srv) as intended for system users.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
