Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky <mjo@gentoo.org>]

On 1/18/20 7:21 PM, Rich Freeman wrote:
> On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky <mjo@gentoo.org> 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
> 

Let's restart:

  * The daemon DOES NOT need a home directory for its user.
  * I DO NOT want to install anything to anyone's home directory.
  * With respect to user.eclass, I'm proposing that /home be treated
    EXACTLY THE SAME as it always has been.

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

Some people want to configure amavis to launch a program like pyzor,
which uses per-user configuration files. If you want to do that, you
first log in as amavis, and run some command like

  $ pyzor discover

which then finds some servers and creates configuration files for you in
$HOME/.pyzor.

This is user configuration, not daemon configuration. It doesn't belong
in the daemon's working directory. In particular, you should not be
dicking around in the daemon's working directory when you run "su
amavis..." because what you're doing is irrelevant to the daemon.

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.

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.


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


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