1 |
On Sun, Jan 19, 2020 at 10:49 AM Michael Orlitzky <mjo@g.o> wrote: |
2 |
> |
3 |
> On 1/19/20 6:29 AM, Rich Freeman wrote: |
4 |
> > |
5 |
> > Daemons are local users. There is no guarantee that /home is a local |
6 |
> > filesystem. Heck, there is no guarantee that /home is even mounted |
7 |
> > when portage is running. Portage shouldn't be touching /home at all. |
8 |
> > With stuff like automounted or encrypted home directories and |
9 |
> > systemd-homed and so on it seems like it is even more important to |
10 |
> > avoid sticking stuff in /home (and this is hardly something started by |
11 |
> > systemd - stuff in /home that is non-static has been a thing for some |
12 |
> > time - certainly it was happening in the 90s on some IRIX workstations |
13 |
> > I used). |
14 |
> |
15 |
> If you're sharing /home, you're also sharing users. At that point, the |
16 |
> daemon user is no longer local. |
17 |
|
18 |
Typically you wouldn't share service accounts across multiple hosts. |
19 |
I'd think that something like amavisd is going to go on a mail server. |
20 |
You're not going to be logging into that account to do typical |
21 |
desktop-oriented functions. |
22 |
|
23 |
If you had three mail servers, you probably would want to share |
24 |
/home/mjo across all of them, but you probably wouldn't want to share |
25 |
your amavisd config across them. That is why the config goes in /etc. |
26 |
I don't see how stuff it launches would be any different. |
27 |
|
28 |
This is why /root is typically outside of /home as well. |
29 |
|
30 |
> I like your /var/lib/amavis/{home,work} suggestion second-best, but the |
31 |
> most appropriate place for the home directory of an account that will be |
32 |
> used interactively by a human (even if it's also used to start a daemon) |
33 |
> is under /home. For example I do want to back up that home directory, |
34 |
> but I don't want to back up the working directory. |
35 |
|
36 |
Honestly, since you're only using it for what amounts to configuration |
37 |
it almost makes sense to put it in /etc, and back it up for that |
38 |
reason. |
39 |
|
40 |
You don't really want to be using it interactively as a human per-se |
41 |
any more than you interactively log in as root or any other service |
42 |
account. There are rare occassions where I'll launch a shell as |
43 |
apache or postfix or whatever, but that doesn't mean that you want it |
44 |
to have a home in /home. |
45 |
|
46 |
> > Portage should provide a safe mechanism to fix permissions. Or we |
47 |
> > should just avoid nesting user home directories inside directories |
48 |
> > that will be written to by that user. |
49 |
> > |
50 |
> > If this is the same hard-linking concern as with tmpfiles.d then |
51 |
> > somebody really just needs to fix POSIX. :) But as a workaround just |
52 |
> > avoiding nesting seems like the simpler solution... |
53 |
> |
54 |
> Essentially yes, but hard links aren't the only problem. It's unsafe to |
55 |
> do anything as root in a user-controlled directory. POSIX can't fix |
56 |
> that, and that means that portage will never be able to fix permissions |
57 |
> (or do anything else) within a user-controlled directory safely. |
58 |
|
59 |
I mean, you're still doing stuff as root. You're just not running chown. |
60 |
|
61 |
POSIX certainly could fix it, though whether it could do it in a |
62 |
manner that doesn't break everything in existence is another matter. |
63 |
For example, if POSIX just got rid of hard links many of the issues |
64 |
would just go away. |
65 |
|
66 |
Obviously if the problem had a simple solution it would have been |
67 |
implemented by now. |
68 |
|
69 |
BTW, thanks to the recent QA post I can at least point you at |
70 |
documentation for your issue. Per the article if you want to change |
71 |
it the procedure is to ask QA for an exception or change in policy, |
72 |
and if you don't like the answer go to Council... |
73 |
|
74 |
https://projects.gentoo.org/qa/policy-guide/filesystem.html#installation-paths |
75 |
|
76 |
-- |
77 |
Rich |