On 1/19/20 12:42 PM, Rich Freeman wrote:
> 
> Typically you wouldn't share service accounts across multiple hosts.
> I'd think that something like amavisd is going to go on a mail server.
> You're not going to be logging into that account to do typical
> desktop-oriented functions.
> 
> If you had three mail servers, you probably would want to share
> /home/mjo across all of them, but you probably wouldn't want to share
> your amavisd config across them.  That is why the config goes in /etc.
> I don't see how stuff it launches would be any different.

The stuff it launches is different because the stuff it launches is
different. SpamAssassin, for example, can be run by normal users in a
traditional UNIX mail setup. So its configuration goes in $HOME, because
that's how it works. When amavis runs spamassassin, the SA configuration
comes from $HOME, because that's how it works.

If you're sharing /home, you also have to be sharing user accounts,
unless you want everyone to be assigned a random set of files. And if
you're sharing user accounts, you have to start each instance of amavis
as a different user, because its configuration is per-user. That's just
the way it works.

Everything is fine here, this all works and has worked for 20 years. If
you have a real scenario where any of this causes a problem, I truly
would like to hear it so that I don't make a mistake. But picking apart
hypothetical scenarios that don't actually apply is making this thread
way longer and more confusing than it has to be.


> You don't really want to be using it interactively as a human per-se
> any more than you interactively log in as root or any other service
> account.  There are rare occassions where I'll launch a shell as
> apache or postfix or whatever, but that doesn't mean that you want it
> to have a home in /home.

You also log in as amavis to e.g. release spam from the quarantine. And
postfix/apache don't need home directories at all, it's not the same.


> I mean, you're still doing stuff as root.  You're just not running chown.
> 
> POSIX certainly could fix it, though whether it could do it in a
> manner that doesn't break everything in existence is another matter.
> For example, if POSIX just got rid of hard links many of the issues
> would just go away.

Hard links are a red herring. Any write or execute operation you intend
to perform as root in my home directory can be subverted in a million
different ways. Hard links just happen to be the stupidest one-line way
to convince people of that fact.

There's already a POSIX solution for changing permissions/ownership:
don't do that. Set umask appropriately, and create files as the user who
should own them. Then you don't have to call chown/chmod to fix the mess
you just created. Running "touch foo.txt && chown mjo foo.txt" as root
in a directory I control is asking for trouble, but if I run "touch
foo.txt" as myself in the same directory... what am I going to do,
escalate privileges to myself?

Reply via email to