[gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[Michael Orlitzky]

It's late and I'm sure this is buggy, but just complaining about it
isn't getting me anywhere.

Michael Orlitzky (2):
  install-qa-check.d: disallow "nix" and "gnu" as top-level paths.
  install-qa-check.d: allow acct-user home directories under /home.

 metadata/install-qa-check.d/08gentoo-paths | 29 ++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

-- 
2.24.1

[gentoo-dev] [PATCH 1/2] install-qa-check.d: disallow "nix" and "gnu" as top-level paths.

[Michael Orlitzky]

These exceptions were made for the sys-apps/nix and sys-apps/guix
packages that are no longer in the tree.
---
 metadata/install-qa-check.d/08gentoo-paths | 2 --
 1 file changed, 2 deletions(-)

diff --git a/metadata/install-qa-check.d/08gentoo-paths b/metadata/install-qa-check.d/08gentoo-paths
index e6cd7e67442..5161aef9922 100644
--- a/metadata/install-qa-check.d/08gentoo-paths
+++ b/metadata/install-qa-check.d/08gentoo-paths
@@ -17,8 +17,6 @@ gentoo_path_check() {
 	local allowed_paths_toplevel=(
 		"${allowed_common_dirs[@]}"
 		boot dev etc opt srv usr var
-		nix # sys-apps/nix, bug #670902
-		gnu # sys-apps/guix, bug #670902
 	)
 
 	# directories in /usr which can be installed to by ebuilds
-- 
2.24.1

Re: [gentoo-dev] [PATCH 1/2] install-qa-check.d: disallow "nix" and "gnu" as top-level paths.

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

On Sun, 2020-01-19 at 22:43 -0500, Michael Orlitzky wrote:
> These exceptions were made for the sys-apps/nix and sys-apps/guix
> packages that are no longer in the tree.
> ---
>  metadata/install-qa-check.d/08gentoo-paths | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/metadata/install-qa-check.d/08gentoo-paths b/metadata/install-qa-check.d/08gentoo-paths
> index e6cd7e67442..5161aef9922 100644
> --- a/metadata/install-qa-check.d/08gentoo-paths
> +++ b/metadata/install-qa-check.d/08gentoo-paths
> @@ -17,8 +17,6 @@ gentoo_path_check() {
>  	local allowed_paths_toplevel=(
>  		"${allowed_common_dirs[@]}"
>  		boot dev etc opt srv usr var
> -		nix # sys-apps/nix, bug #670902
> -		gnu # sys-apps/guix, bug #670902
>  	)
>  
>  	# directories in /usr which can be installed to by ebuilds

Oh, were they removed already?  In that case LGTM.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

[gentoo-dev] [PATCH 2/2] install-qa-check.d: allow acct-user home directories under /home.

[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.

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
-- 
2.24.1

Re: [gentoo-dev] [PATCH 2/2] install-qa-check.d: allow acct-user home directories under /home.

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 4572 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [PATCH 2/2] install-qa-check.d: allow acct-user home directories under /home.

[Andreas K. Huettel]

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
dilfridge@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.

[Michael Orlitzky]

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.

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

>>>>> On Mon, 20 Jan 2020, Michael Orlitzky wrote:

>   install-qa-check.d: allow acct-user home directories under /home.

Nope. As you've been told, /home is site specific and can be setup in
multiple ways that are incompatible with the package manager installing
things there (the only exception being baselayout creating the directory
itself).

Quoting FHS-3.0 again:

| On large systems (especially when the /home directories are shared
| amongst many hosts using NFS) it is useful to subdivide user home
| directories. Subdivision may be accomplished by using subdirectories
| such as /home/staff, /home/guests, /home/students, etc.

So, how are you going to detect if such a scheme is used on the system,
and in which subdirectory the amavis user should be placed?

I also wonder why you would send this patch, when there wasn't a single
voice supporting your proposition in the other thread and several
opposing ones.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[Michael Orlitzky]

On 1/20/20 2:02 AM, Ulrich Mueller wrote:
>>>>>> On Mon, 20 Jan 2020, Michael Orlitzky wrote:
> 
>>   install-qa-check.d: allow acct-user home directories under /home.
> 
> Nope. As you've been told, /home is site specific and can be setup in
> multiple ways that are incompatible with the package manager installing
> things there (the only exception being baselayout creating the directory
> itself).

I haven't been given a single technical reason why using /home would
cause a problem. What specific incompatibilities are you talking about?


> Quoting FHS-3.0 again:
> 
> | On large systems (especially when the /home directories are shared
> | amongst many hosts using NFS) it is useful to subdivide user home
> | directories. Subdivision may be accomplished by using subdirectories
> | such as /home/staff, /home/guests, /home/students, etc.
> 
> So, how are you going to detect if such a scheme is used on the system,
> and in which subdirectory the amavis user should be placed?

The same way we detect that scheme before setting a home directory to
/var/lib/whatever, which you may notice, is not under /home/guests or
anything like that. Does this cause a real technical problem, or is it
just more FUD?


> I also wonder why you would send this patch, when there wasn't a single
> voice supporting your proposition in the other thread and several
> opposing ones.

I don't want to just complain without offering a solution.

No one has pointed out any problems with it.

This stuff is already in /home, and I'd like to get off user.eclass
without introducing a new QA warning for a keepdir file.

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[David Seifert]

On Mon, 2020-01-20 at 09:20 -0500, Michael Orlitzky wrote:
> On 1/20/20 2:02 AM, Ulrich Mueller wrote:
> > > > > > > On Mon, 20 Jan 2020, Michael Orlitzky wrote:
> > >   install-qa-check.d: allow acct-user home directories under
> > > /home.
> > 
> > Nope. As you've been told, /home is site specific and can be setup
> > in
> > multiple ways that are incompatible with the package manager
> > installing
> > things there (the only exception being baselayout creating the
> > directory
> > itself).
> 
> I haven't been given a single technical reason why using /home would
> cause a problem. What specific incompatibilities are you talking
> about?
> 
> 
> > Quoting FHS-3.0 again:
> > 
> > > On large systems (especially when the /home directories are
> > > shared
> > > amongst many hosts using NFS) it is useful to subdivide user home
> > > directories. Subdivision may be accomplished by using
> > > subdirectories
> > > such as /home/staff, /home/guests, /home/students, etc.
> > 
> > So, how are you going to detect if such a scheme is used on the
> > system,
> > and in which subdirectory the amavis user should be placed?
> 
> The same way we detect that scheme before setting a home directory to
> /var/lib/whatever, which you may notice, is not under /home/guests or
> anything like that. Does this cause a real technical problem, or is
> it
> just more FUD?

Rich has given reasons, ulm has, and mgorny suggested a solution.

> 
> > I also wonder why you would send this patch, when there wasn't a
> > single
> > voice supporting your proposition in the other thread and several
> > opposing ones.
> 
> I don't want to just complain without offering a solution.
> 
> No one has pointed out any problems with it.

Multiple people have pointed out issues with it in the last thread. In
fact, noone has said "great, go ahead".

> 
> This stuff is already in /home, and I'd like to get off user.eclass
> without introducing a new QA warning for a keepdir file.
> 

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[Michael Orlitzky]

On 1/20/20 9:50 AM, David Seifert wrote:
> 
> Rich has given reasons, ulm has, and mgorny suggested a solution.
> 

Everyone's real intent on saying that there are problems without
actually typing what those problems are into the email box.

We're talking about a single keepdir file here.

Please describe in detail the havoc that this could cause and under what
precise circumstances.

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On Mon, 2020-01-20 at 10:20 -0500, Michael Orlitzky wrote:
> On 1/20/20 9:50 AM, David Seifert wrote:
> > Rich has given reasons, ulm has, and mgorny suggested a solution.
> > 
> 
> Everyone's real intent on saying that there are problems without
> actually typing what those problems are into the email box.
> 
> We're talking about a single keepdir file here.
> 
> Please describe in detail the havoc that this could cause and under what
> precise circumstances.
> 

I'm going to be blunt.  We arbitrarily made a decision that /home
belongs to sysadmin.  Please respect that.  If you really believe your
package is *this* special to justify changing this arbitrary decision,
the burden of proof lies on you.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[Michael Orlitzky]

On 1/20/20 1:39 PM, Michał Górny wrote:
> 
> I'm going to be blunt.  We arbitrarily made a decision that /home
> belongs to sysadmin.  Please respect that.  If you really believe your
> package is *this* special to justify changing this arbitrary decision,
> the burden of proof lies on you.
> 

Ok. How to move forward?

The old user.eclass allowed using /home, and we have packages using
/home. One of them is spamd, and I've beaten to death the reasons why I
think that's the best choice. I would rather not move it somewhere
*less* appropriate on principle. I would also like to not break running
mail systems the second the acct-user package is emerged.

What are the options?

  * Upgrade to GLEP81 anyway and ignore the warning (my interim plan).

  * Hack the acct-user ebuild so that it doesn't trigger the warning, by
    bypassing $D.

  * Leave it on user.eclass.

  * ???

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]

>>>>> On Mon, 20 Jan 2020, Michael Orlitzky wrote:

> On 1/20/20 2:02 AM, Ulrich Mueller wrote:
>> Quoting FHS-3.0 again:
>> 
>> | On large systems (especially when the /home directories are shared
>> | amongst many hosts using NFS) it is useful to subdivide user home
>> | directories. Subdivision may be accomplished by using subdirectories
>> | such as /home/staff, /home/guests, /home/students, etc.
>> 
>> So, how are you going to detect if such a scheme is used on the system,
>> and in which subdirectory the amavis user should be placed?

> The same way we detect that scheme before setting a home directory to
> /var/lib/whatever, which you may notice, is not under /home/guests or
> anything like that. Does this cause a real technical problem, or is it
> just more FUD?

It's just awful to have a one user at second level (like /home/amavis)
when all others are at third level (like /home/staff/joe).

Besides, nothing guarantees that your username under /home won't collide
with an existing subdirectory name.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[Michael Orlitzky]

On 1/20/20 1:01 PM, Ulrich Mueller wrote:
> 
> It's just awful to have a one user at second level (like /home/amavis)
> when all others are at third level (like /home/staff/joe).
> 

Finally an honest argument =)

I agree. But all we're doing is choosing the default here. GLEP81 lets
the user override the home directory in those rare cases to put it under
/home/guests. For everyone else, you get

  /home/user1
  /home/user2
  /home/user3
  /home/user4

instead of

  /home/user1
  /home/user2
  /var/lib/user3/home
  /home/user4

I think it's weird that my bash_history winds up under /var/lib.


> Besides, nothing guarantees that your username under /home won't collide
> with an existing subdirectory name. 

You can make the same argument about /var/lib. And keep in mind that we
already have "collisions" for $HOME every time someone switches from
user.eclass to a GLEP81 user. The risk for /home is no greater than
anywhere else, and we've deemed that risk acceptable, whatever it is.

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 3832 bytes --]

On Mon, Jan 20, 2020 at 6:20 AM Michael Orlitzky <mjo@gentoo.org> wrote:

> On 1/20/20 2:02 AM, Ulrich Mueller wrote:
> >>>>>> On Mon, 20 Jan 2020, Michael Orlitzky wrote:
> >
> >>   install-qa-check.d: allow acct-user home directories under /home.
> >
> > Nope. As you've been told, /home is site specific and can be setup in
> > multiple ways that are incompatible with the package manager installing
> > things there (the only exception being baselayout creating the directory
> > itself).
>
> I haven't been given a single technical reason why using /home would
> cause a problem. What specific incompatibilities are you talking about?
>

So I can describe in detail one example, but its not running Gentoo; so I'm
not sure if you care in practice.

At work we had sec=krb5 NFS v3 mounted home directories. They were mounted
in /home (via the automounter.) So if these machines ran Gentoo and you
went to do something like "create /home/amavisd" it would fail because the
root user doesn't have the ability to make home directories in /home (uid=0
is mapped to nobody, who doesn't have +w on /home.) All home directories
were created by a business application and there were specific hosts where
root was not squashed (and we used sec=sys instead of krb5) and so root on
the admin host would have +w on /home and not be squashed to nobody.)

In practice in that enterprise environment, if we needed something like
/home/web/ (which I think did exist at one point) we would create a role
account in LDAP (www-data is a common user for example), assign it a uid,
create the homedirectory (/home/web) and it would be owned by
www-data:www-data. Then we would configure the web front ends to use
www-data instead of the normal user (apache or nginx or whatever.)

In practice:
(1) These environments are what I'd consider legacy; if I was crafting an
enterprise environment today I would not design one quite like this[0].
(2) I don't think most people running Gentoo are running these
environments, which is why you don't see many practical objections on the
list. I think it's reasonable to avoid service account homedirs in /home
not because of fancy examples like above (that maybe 10 companies in the
world run) and instead just focus on this idea that "system stuff doesn't
go in /home." Its somewhat arbitrary as mgorny points out earlier in the
thread.

-A

[0] Linux has really poor machine trust by default and while you can build
a ragtag set of primitives to trust machines and identities; I think the
effort is better spent shelling out money for some kind of real identity
management provider that isn't just 'hey here is a uid + ip' which is how
we did things in the 90s man. It was an innocent time ;)



>
> > Quoting FHS-3.0 again:
> >
> > | On large systems (especially when the /home directories are shared
> > | amongst many hosts using NFS) it is useful to subdivide user home
> > | directories. Subdivision may be accomplished by using subdirectories
> > | such as /home/staff, /home/guests, /home/students, etc.
> >
> > So, how are you going to detect if such a scheme is used on the system,
> > and in which subdirectory the amavis user should be placed?
>
> The same way we detect that scheme before setting a home directory to
> /var/lib/whatever, which you may notice, is not under /home/guests or
> anything like that. Does this cause a real technical problem, or is it
> just more FUD?
>
>
> > I also wonder why you would send this patch, when there wasn't a single
> > voice supporting your proposition in the other thread and several
> > opposing ones.
>
> I don't want to just complain without offering a solution.
>
> No one has pointed out any problems with it.
>
> This stuff is already in /home, and I'd like to get off user.eclass
> without introducing a new QA warning for a keepdir file.
>
>

[-- Attachment #2: Type: text/html, Size: 4766 bytes --]

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[Michael Orlitzky]

On 1/20/20 5:08 PM, Alec Warner wrote:
> 
> So I can describe in detail one example, but its not running Gentoo; so
> I'm not sure if you care in practice.

Yes, I'm happy to see a real example.


> At work we had sec=krb5 NFS v3 mounted home directories. They were
> mounted in /home (via the automounter.) So if these machines ran Gentoo
> and you went to do something like "create /home/amavisd" it would fail
> because the root user doesn't have the ability to make home directories
> in /home (uid=0 is mapped to nobody, who doesn't have +w on /home.) All
> home directories were created by a business application and there were
> specific hosts where root was not squashed (and we used sec=sys instead
> of krb5) and so root on the admin host would have +w on /home and not be
> squashed to nobody.)
>
> In practice in that enterprise environment, if we needed something like
> /home/web/ (which I think did exist at one point) we would create a role
> account in LDAP (www-data is a common user for example), assign it a
> uid, create the homedirectory (/home/web) and it would be owned by
> www-data:www-data. Then we would configure the web front ends to use
> www-data instead of the normal user (apache or nginx or whatever.)

That's all relatively normal. As I've said, a human uses the "amavis"
account. Yes, the install of acct-user/amavis would crash because it
can't create the home directory, but I contend that crashing is the best
thing to do.

When the acct-user ebuild crashes, you get to ask yourself if you want
his home directory to be shared among the people with authority to
release spam from the quarantine. I'm betting you would, and that you
would therefore add the account to LDAP and start over. Same deal as
apache/web, and you don't have to involve an overlay to do the right
thing. In this case, the fact that we used /home was a boon, because it
helped you accomplish what you were trying to accomplish by sharing
/home in the first place.

If you don't want to share the home directory... well, no harm done.
You'll have to override the ebuild to tell it what location to use as an
alternative. But I think this case is somewhat less likely, and the base
rate was already single digits.

If only good exceptions are made (with home directories that people
would actually want to share under /home), this approach does a little
good and no bad.



> (2) I don't think most people running Gentoo are running these
> environments, which is why you don't see many practical objections on
> the list. I think it's reasonable to avoid service account homedirs in
> /home not because of fancy examples like above (that maybe 10 companies
> in the world run) and instead just focus on this idea that "system stuff
> doesn't go in /home." Its somewhat arbitrary as mgorny points out
> earlier in the thread.

I was never discounting these sorts of environments. On the contrary,
the point I'm trying to make above appeared somewhere in the discussion
with rich0, but it's hard to articulate without details.

If it's arbitrary and we admit that, I'm fine with it. I'm moving on
with my life. QA can choose what kind of sauce users get on their turd
sandwich =P

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

On Mon, Jan 20, 2020 at 06:07:06PM -0500, Michael Orlitzky wrote:
> As I've said, a human uses the "amavis" account.
I think this statement here needs a bit of expansion, and thus it more
clarity happens.

Your aforementioned human generally doesn't use the 'amavis' account in
the same way that they might use a normal account. They don't expect to
login to it with GNOME/SSH and run typical user applications
(Libreoffice, Nethack etc.).

It's a system account that CAN get configured by a human manually
becoming that user. Either by login or means of changing effective UID
(su, sudo, doas, ksu, pmrun, runas, ...).

For a more secure environment, I would expect amavis to never have a
password and thus not be subject to normal login flows.

Gentoo Infra manages amavis & spamd without logging in as a human:
configuration management is used to change settings & files.

From this, I posit that something OUTSIDE of /home is the most-correct
location. /srv or /var.

Upstream uses /var/amavis
Debian uses /var/lib/amavis

I'm sympathetic to past users who have /home/amavisd and need to
migrate it, but such is the nature of sysadmin life.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[Jaco Kroon]

Hi Michael,

My background:  21 years of Linux, 18 of which was primarily on Gentoo. 
17 years of no other OS other than Linux.  Ex-sysadmin for a largish
setup with 4000+ active users, and ~500-600 available workstations and a
number of storage and other servers.  Not to brag, just to give you an
idea of my background and experience.

I am against this patch.

On 2020/01/20 16:20, Michael Orlitzky wrote:

> On 1/20/20 2:02 AM, Ulrich Mueller wrote:
>>>>>>> On Mon, 20 Jan 2020, Michael Orlitzky wrote:
>>>   install-qa-check.d: allow acct-user home directories under /home.
>> Nope. As you've been told, /home is site specific and can be setup in
>> multiple ways that are incompatible with the package manager installing
>> things there (the only exception being baselayout creating the directory
>> itself).
> I haven't been given a single technical reason why using /home would
> cause a problem. What specific incompatibilities are you talking about?

From my perspective the following should be adequate:

There is technically no real issue, but it's the right thing to do.

Right, motivations for your proposal for allowing this:

* You want it.

Motivations against:

* /home belongs to the sys-admin.  In above environment if you were to
mess with my /home, I'd be very, very angry.
* installing stuff into /home using system-local UIDs has potential
security impacts if /home is distributed (user id conflicts).
* People mentioned encrypted home folders using LUKS ... these typically
mount on /home/${username} so I personally think this is less of an issue.
* FHS standards (back to it's the right thing to do).
* I've worked on numerous distributions (Debian, Ubuntu, RHEL, SuSE,
Fedora, Mint, IMPI, knoppix ... probably others) and not once have I
encountered system packages messing with /home.  Not having encountered
it doesn't say there isn't any, just that I've not encountered them.

>
>
>> Quoting FHS-3.0 again:
>>
>> | On large systems (especially when the /home directories are shared
>> | amongst many hosts using NFS) it is useful to subdivide user home
>> | directories. Subdivision may be accomplished by using subdirectories
>> | such as /home/staff, /home/guests, /home/students, etc.
>>
>> So, how are you going to detect if such a scheme is used on the system,
>> and in which subdirectory the amavis user should be placed?
> The same way we detect that scheme before setting a home directory to
> /var/lib/whatever, which you may notice, is not under /home/guests or
> anything like that. Does this cause a real technical problem, or is it
> just more FUD?

It's not FUD, there is no fear here, no uncertainty, no doubt.  We don't
*want* you to touch /home.  We want you to use /var/lib.

>
>> I also wonder why you would send this patch, when there wasn't a single
>> voice supporting your proposition in the other thread and several
>> opposing ones.
> I don't want to just complain without offering a solution.
>
> No one has pointed out any problems with it.
>
> This stuff is already in /home, and I'd like to get off user.eclass
> without introducing a new QA warning for a keepdir file.

Use /var/lib/amavis/work and /var/lib/amavis/home.  Simple.

Kind Regards,
Jaco

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

[Michael Orlitzky]

On 1/21/20 6:44 AM, Jaco Kroon wrote:
> 
> There is technically no real issue, but it's the right thing to do.
> 
> Right, motivations for your proposal for allowing this:
> 
> * You want it.
> 
> Motivations against:
> 

This is dishonest. "I want it" because it improves some things for our
users, which you've purposely omitted.

I was never going to commit the patch. If anyone wants to discuss the
technical merits of using /home, I find it interesting, but please let
this thread die and just email me personally or ping me on IRC.