Re: [gentoo-dev] GLEP81 and /home

[Rich Freeman]

On Sat, Jan 18, 2020 at 9:50 PM Michael Orlitzky <mjo@g.o> wrote:
>
> On 1/18/20 7:21 PM, Rich Freeman wrote:
> > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky <mjo@g.o> wrote:
> >>
> >> But now users have to follow one more step (create /home/amavis) when
> >> setting up amavisd-new. Is the QA check really assuring a quality user
> >> experience here?
> >>
> >
> > Lots of daemons need a home directory for their users, and usually
> > they manage to get by in /var/lib.  It really seems like a bad
> > practice to start having packages creating stuff in /home.  Certainly
> > I don't want random daemons sticking stuff in /home, which I manage
> >
>
>   * The daemon DOES NOT need a home directory for its user.
>   * I DO NOT want to install anything to anyone's home directory.

My concern isn't with installing stuff to "anyone's home directory."
My concern is with creating ANYTHING in /home.

Daemons are local users.  There is no guarantee that /home is a local
filesystem.  Heck, there is no guarantee that /home is even mounted
when portage is running.  Portage shouldn't be touching /home at all.
With stuff like automounted or encrypted home directories and
systemd-homed and so on it seems like it is even more important to
avoid sticking stuff in /home (and this is hardly something started by
systemd - stuff in /home that is non-static has been a thing for some
time - certainly it was happening in the 90s on some IRIX workstations
I used).

>   * With respect to user.eclass, I'm proposing that /home be treated
>     EXACTLY THE SAME as it always has been.

I'm not aware that it was ever considered good practice to stick stuff
in /home.  I suspect it just wasn't on QA's radar in the past.

>
> All I want to do is *set* a user's home directory to /home/foo.

You don't just want to "set" it.  You want to create the directory,
which is modifying the filesystem (otherwise, why have a .keepdir?).
And setting a home directory to something that doesn't exist doesn't
seem like an improvement unless it is /dev/null.

I get though that the daemon itself doesn't use the home directory,
and that you just want it for configuring other stuff it might launch.

> Spamassassin itself is a better example than amavis. We already set the
> spamd user's home directory to /home/spamd with user.eclass. We don't
> install anything there, and this works fine. If a human logs into that
> account and generates some configuration in ~/.spamassassin, then it's
> within the spirit of the FHS to have that data stored in /home.

Looks like we might have another package to deal with, and perhaps
others as well, depending on what comes out of this thread.

> Now, with GLEP 81, we get a QA warning for that, because the eclass
> installs a keepdir file there. I would like things to remain exactly as
> they are, with no QA warning. Otherwise, we have to tell users to move
> /home/spamd to /var/lib/spamd-home or something stupid like that. I can
> think of no good reason to do so.

Well, you won't get QA warnings from the tinderbox if the default home
isn't under /home.  Users who already have the home there might get
warnings at install time.  They can just ignore them.  You could
output an einfo to explain the situation to the user.  If they're fine
with /home then they can ignore the warning, and if they want to move
it they can do so.

I'll also note that GLEP 81 itself is silent on WHERE home directories
should be placed.  If some sort of definitive answer comes out of this
thread the GLEP should probably be updated to reflect this, unless
there is a better place to put it.  Seems like the fact that this
practice was undocumented in the past is part of how we got to where
we're at.

> > It seems like the straightforward solution is to stick everything in
> > /var/lib/amavis, and fix things so that everything has the right
> > permissions regardless of install order.
>
> Please stop telling people to do this. Calling chown on the live
> filesystem is rarely safe, and I already fixed one root exploit (bug
> 630836) in the amavisd-new ebuild from the last guy who tried to adjust
> wrong permissions after the fact.

That bug appears to be restricted.  Perhaps it is embargoed?  If not,
then it probably shouldn't be restricted, especially if already fixed
and GLSA'ed (and if it wasn't GLSA'ed then it isn't fixed, not that
this has anything to do with you most likely).

Portage should provide a safe mechanism to fix permissions.  Or we
should just avoid nesting user home directories inside directories
that will be written to by that user.

If this is the same hard-linking concern as with tmpfiles.d then
somebody really just needs to fix POSIX.  :)  But as a workaround just
avoiding nesting seems like the simpler solution...

Just on a side note, I'm just stating an opinion here.  I'm not in QA.
Nobody should be construing my posts as "telling people" to do
anything.  And I do realize that you're just inheriting a situation
that goes back probably quite a long time - please don't take anything
as a personal criticism.  Maybe this stuff wasn't entirely thought out
in the past, but going forward we should try to come up with the best
solution, and then try to find the most reasonable way to get from
here to there.

> > Another option is to have /var/lib/amavis/home and /var/lib/amavis/work.
>
> This is better-looking than /var/lib/amavis-home, but it's still
> violating the spirit of the FHS to avoid triggering a warning on a dummy
> file.

Do you have a more FHS-compliant suggestion?  Clearly /home isn't
particularly FHS-compliant:

/home is a fairly standard concept, but it is clearly a site-specific
filesystem. The setup will differ from host to host.
Non-login accounts created for administrative purposes often have
their home directories elsewhere.

This actually seems like a bit of an FHS gap.  IMO /var/lib is the
lesser evil here, but if there is something else more FHS-appropriate
that could work.  FHS says that users shouldn't have to touch /var/lib
to configure a daemon, but as you've pointed out this isn't about
configuring the daemon itself, but rather helpers that it might run
after the user configures it to do so.

-- 
Rich