Gentoo Archives: gentoo-dev

From: Michael Orlitzky <mjo@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] GLEP81 and /home
Date: Sun, 19 Jan 2020 02:50:28
Message-Id: c54aabbc-e471-4f81-64ff-c2d0432e1519@gentoo.org
In Reply to: Re: [gentoo-dev] GLEP81 and /home by Rich Freeman
1 On 1/18/20 7:21 PM, Rich Freeman wrote:
2 > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky <mjo@g.o> wrote:
3 >>
4 >> But now users have to follow one more step (create /home/amavis) when
5 >> setting up amavisd-new. Is the QA check really assuring a quality user
6 >> experience here?
7 >>
8 >
9 > Lots of daemons need a home directory for their users, and usually
10 > they manage to get by in /var/lib. It really seems like a bad
11 > practice to start having packages creating stuff in /home. Certainly
12 > I don't want random daemons sticking stuff in /home, which I manage
13 >
14
15 Let's restart:
16
17 * The daemon DOES NOT need a home directory for its user.
18 * I DO NOT want to install anything to anyone's home directory.
19 * With respect to user.eclass, I'm proposing that /home be treated
20 EXACTLY THE SAME as it always has been.
21
22 All I want to do is *set* a user's home directory to /home/foo.
23
24 Some people want to configure amavis to launch a program like pyzor,
25 which uses per-user configuration files. If you want to do that, you
26 first log in as amavis, and run some command like
27
28 $ pyzor discover
29
30 which then finds some servers and creates configuration files for you in
31 $HOME/.pyzor.
32
33 This is user configuration, not daemon configuration. It doesn't belong
34 in the daemon's working directory. In particular, you should not be
35 dicking around in the daemon's working directory when you run "su
36 amavis..." because what you're doing is irrelevant to the daemon.
37
38 Spamassassin itself is a better example than amavis. We already set the
39 spamd user's home directory to /home/spamd with user.eclass. We don't
40 install anything there, and this works fine. If a human logs into that
41 account and generates some configuration in ~/.spamassassin, then it's
42 within the spirit of the FHS to have that data stored in /home.
43
44 Now, with GLEP 81, we get a QA warning for that, because the eclass
45 installs a keepdir file there. I would like things to remain exactly as
46 they are, with no QA warning. Otherwise, we have to tell users to move
47 /home/spamd to /var/lib/spamd-home or something stupid like that. I can
48 think of no good reason to do so.
49
50
51 > It seems like the straightforward solution is to stick everything in
52 > /var/lib/amavis, and fix things so that everything has the right
53 > permissions regardless of install order.
54
55 Please stop telling people to do this. Calling chown on the live
56 filesystem is rarely safe, and I already fixed one root exploit (bug
57 630836) in the amavisd-new ebuild from the last guy who tried to adjust
58 wrong permissions after the fact.
59
60
61 > Another option is to have /var/lib/amavis/home and /var/lib/amavis/work.
62
63 This is better-looking than /var/lib/amavis-home, but it's still
64 violating the spirit of the FHS to avoid triggering a warning on a dummy
65 file.

Replies

Subject Author
Re: [gentoo-dev] GLEP81 and /home Rich Freeman <rich0@g.o>
Re: [gentoo-dev] GLEP81 and /home Alec Warner <antarus@g.o>