On Sat, Jan 18, 2020 at 6:50 PM Michael Orlitzky <mjo@gentoo.org> wrote:

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

Why wouldn't you set the homedirectory to /dev/null then?

-A


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