1 |
On 1/19/20 12:42 PM, Rich Freeman wrote: |
2 |
> |
3 |
> Typically you wouldn't share service accounts across multiple hosts. |
4 |
> I'd think that something like amavisd is going to go on a mail server. |
5 |
> You're not going to be logging into that account to do typical |
6 |
> desktop-oriented functions. |
7 |
> |
8 |
> If you had three mail servers, you probably would want to share |
9 |
> /home/mjo across all of them, but you probably wouldn't want to share |
10 |
> your amavisd config across them. That is why the config goes in /etc. |
11 |
> I don't see how stuff it launches would be any different. |
12 |
|
13 |
The stuff it launches is different because the stuff it launches is |
14 |
different. SpamAssassin, for example, can be run by normal users in a |
15 |
traditional UNIX mail setup. So its configuration goes in $HOME, because |
16 |
that's how it works. When amavis runs spamassassin, the SA configuration |
17 |
comes from $HOME, because that's how it works. |
18 |
|
19 |
If you're sharing /home, you also have to be sharing user accounts, |
20 |
unless you want everyone to be assigned a random set of files. And if |
21 |
you're sharing user accounts, you have to start each instance of amavis |
22 |
as a different user, because its configuration is per-user. That's just |
23 |
the way it works. |
24 |
|
25 |
Everything is fine here, this all works and has worked for 20 years. If |
26 |
you have a real scenario where any of this causes a problem, I truly |
27 |
would like to hear it so that I don't make a mistake. But picking apart |
28 |
hypothetical scenarios that don't actually apply is making this thread |
29 |
way longer and more confusing than it has to be. |
30 |
|
31 |
|
32 |
> You don't really want to be using it interactively as a human per-se |
33 |
> any more than you interactively log in as root or any other service |
34 |
> account. There are rare occassions where I'll launch a shell as |
35 |
> apache or postfix or whatever, but that doesn't mean that you want it |
36 |
> to have a home in /home. |
37 |
|
38 |
You also log in as amavis to e.g. release spam from the quarantine. And |
39 |
postfix/apache don't need home directories at all, it's not the same. |
40 |
|
41 |
|
42 |
> I mean, you're still doing stuff as root. You're just not running chown. |
43 |
> |
44 |
> POSIX certainly could fix it, though whether it could do it in a |
45 |
> manner that doesn't break everything in existence is another matter. |
46 |
> For example, if POSIX just got rid of hard links many of the issues |
47 |
> would just go away. |
48 |
|
49 |
Hard links are a red herring. Any write or execute operation you intend |
50 |
to perform as root in my home directory can be subverted in a million |
51 |
different ways. Hard links just happen to be the stupidest one-line way |
52 |
to convince people of that fact. |
53 |
|
54 |
There's already a POSIX solution for changing permissions/ownership: |
55 |
don't do that. Set umask appropriately, and create files as the user who |
56 |
should own them. Then you don't have to call chown/chmod to fix the mess |
57 |
you just created. Running "touch foo.txt && chown mjo foo.txt" as root |
58 |
in a directory I control is asking for trouble, but if I run "touch |
59 |
foo.txt" as myself in the same directory... what am I going to do, |
60 |
escalate privileges to myself? |