Gentoo Archives: gentoo-dev

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

Replies

Subject Author
Re: [gentoo-dev] GLEP81 and /home Michael Orlitzky <mjo@g.o>