[gentoo-dev] GLEP81 and /home

[gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

We forbid packages from installing to /home for good reason: for most of
history, users (and their home directories) were outside the purview of
the package manager. But with GLEP81, that's changed: the package
manager is now in charge of creating each system user's home directory
and of giving it the correct permissions and ownership.

Is the policy against installing to /home still consistent?

For example: the mail-filter/amavisd-new daemon needs a user, typically
called "amavis". The daemon also needs a working directory that it can
write to. The obvious choice for a working directory is /var/lib/amavis,
but there's a catch: spamassassin, razor, pyzor, et cetera (which are
all used by amavis) store their configuration in the current user's home
directory, and not in some daemon-specific location. So "amavis" needs a
home directory, because that's where much of the configuration for
amavisd goes.

Where do we put amavis's home directory?

  1 /var/lib/amavis is a bad idea, because it conflicts with the working
    directory (we don't want the two packages to get out of sync, nor do
    we want to keep them in-sync manually).

  2 /var/lib/amavis/home was my next choice, because logically it puts
    the amavisd configuration in a subdirectory of the place where all
    of the other amavis stuff goes, and because it doesn't have the
    same issue that (1) does.

    But there's a problem: if we create /var/lib/amavis/home before
    amavisd-new is installed (as happens when you emerge amavisd-new),
    then /var/lib/amavis winds up root:root and the installation of
    amavisd-new doesn't change that. So now amavisd-new doesn't work,
    because it can't write to its working directory.

    This is a combination of an implementation detail and the fact that
    the PMS doesn't cover directories; but ultimately, it just doesn't
    work reliably.

  3 /home/amavis also seems fine to me, except for the fact that it's a
    QA violation to install there.

Note that we could always set system users' home directories to
/home/whatever. It has only become a QA violation with GLEP81 because
the eclass calls keepdir on the user's home directory.

Should option (3) be viable, or do I go back to the drawing board?

Re: [gentoo-dev] GLEP81 and /home

[Ulrich Mueller]

>>>>> On Sat, 18 Jan 2020, Michael Orlitzky wrote:

> Where do we put amavis's home directory?
> [...]

>   3 /home/amavis also seems fine to me, except for the fact that it's a
>     QA violation to install there.

> Note that we could always set system users' home directories to
> /home/whatever. It has only become a QA violation with GLEP81 because
> the eclass calls keepdir on the user's home directory.

> Should option (3) be viable, or do I go back to the drawing board?

Chances are that /home is site specific, e.g. with a special backup
policy, or shared between many hosts via NFS. So IMHO /home is off
limits for the package manager.

Your original idea of placing it somewhere under /var/lib sounds just
right.

Ulrich

Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

On 1/18/20 1:10 PM, Ulrich Mueller wrote:
> 
>> Should option (3) be viable, or do I go back to the drawing board?
> 
> Chances are that /home is site specific, e.g. with a special backup
> policy, or shared between many hosts via NFS. So IMHO /home is off
> limits for the package manager.
> 

We don't actually install anything there except the keepdir file, which
is why this used to work with user.eclass. If someone later logs in as
"amavis" and creates some configuration in $HOME, then that stuff is
subject to your backup/sharing policy just like any other user data.

I could always just use /home/amavis as $HOME and un-keepdir that
location. We don't really care if the directory exists, until/unless
someone logs in and starts adding configuration, so that's semantically
correct. No permissions problems and no QA warnings either.

But now users have to follow one more step (create /home/amavis) when
setting up amavisd-new. Is the QA check really assuring a quality user
experience here?

Re: [gentoo-dev] GLEP81 and /home

[Rich Freeman]

On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> But now users have to follow one more step (create /home/amavis) when
> setting up amavisd-new. Is the QA check really assuring a quality user
> experience here?
>

Lots of daemons need a home directory for their users, and usually
they manage to get by in /var/lib.  It really seems like a bad
practice to start having packages creating stuff in /home.  Certainly
I don't want random daemons sticking stuff in /home, which I manage
differently from the OS-owned directories.  I'll just end up having to
manually create stuff where it belongs in /var/lib and then symlink
everything back from /home, and now I have distro cruft in /home and
non-distro cruft in /var/lib, and neither is ideal.

It seems like the straightforward solution is to stick everything in
/var/lib/amavis, and fix things so that everything has the right
permissions regardless of install order.

If /var/lib/amavis is getting installed root-owned then it should be
chowned when amavis is installed, especially for the first time.  That
seems sane.

Another option is to have /var/lib/amavis/home and /var/lib/amavis/work.

-- 
Rich

Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

On 1/18/20 7:21 PM, Rich Freeman wrote:
> On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>>
>> But now users have to follow one more step (create /home/amavis) when
>> setting up amavisd-new. Is the QA check really assuring a quality user
>> experience here?
>>
> 
> Lots of daemons need a home directory for their users, and usually
> they manage to get by in /var/lib.  It really seems like a bad
> practice to start having packages creating stuff in /home.  Certainly
> I don't want random daemons sticking stuff in /home, which I manage
> 

Let's restart:

  * The daemon DOES NOT need a home directory for its user.
  * I DO NOT want to install anything to anyone's home directory.
  * With respect to user.eclass, I'm proposing that /home be treated
    EXACTLY THE SAME as it always has been.

All I want to do is *set* a user's home directory to /home/foo.

Some people want to configure amavis to launch a program like pyzor,
which uses per-user configuration files. If you want to do that, you
first log in as amavis, and run some command like

  $ pyzor discover

which then finds some servers and creates configuration files for you in
$HOME/.pyzor.

This is user configuration, not daemon configuration. It doesn't belong
in the daemon's working directory. In particular, you should not be
dicking around in the daemon's working directory when you run "su
amavis..." because what you're doing is irrelevant to the daemon.

Spamassassin itself is a better example than amavis. We already set the
spamd user's home directory to /home/spamd with user.eclass. We don't
install anything there, and this works fine. If a human logs into that
account and generates some configuration in ~/.spamassassin, then it's
within the spirit of the FHS to have that data stored in /home.

Now, with GLEP 81, we get a QA warning for that, because the eclass
installs a keepdir file there. I would like things to remain exactly as
they are, with no QA warning. Otherwise, we have to tell users to move
/home/spamd to /var/lib/spamd-home or something stupid like that. I can
think of no good reason to do so.


> It seems like the straightforward solution is to stick everything in
> /var/lib/amavis, and fix things so that everything has the right
> permissions regardless of install order.

Please stop telling people to do this. Calling chown on the live
filesystem is rarely safe, and I already fixed one root exploit (bug
630836) in the amavisd-new ebuild from the last guy who tried to adjust
wrong permissions after the fact.


> Another option is to have /var/lib/amavis/home and /var/lib/amavis/work.

This is better-looking than /var/lib/amavis-home, but it's still
violating the spirit of the FHS to avoid triggering a warning on a dummy
file.

Re: [gentoo-dev] GLEP81 and /home

[Rich Freeman]

On Sat, Jan 18, 2020 at 9:50 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> On 1/18/20 7:21 PM, Rich Freeman wrote:
> > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky <mjo@gentoo.org> wrote:
> >>
> >> But now users have to follow one more step (create /home/amavis) when
> >> setting up amavisd-new. Is the QA check really assuring a quality user
> >> experience here?
> >>
> >
> > Lots of daemons need a home directory for their users, and usually
> > they manage to get by in /var/lib.  It really seems like a bad
> > practice to start having packages creating stuff in /home.  Certainly
> > I don't want random daemons sticking stuff in /home, which I manage
> >
>
>   * The daemon DOES NOT need a home directory for its user.
>   * I DO NOT want to install anything to anyone's home directory.

My concern isn't with installing stuff to "anyone's home directory."
My concern is with creating ANYTHING in /home.

Daemons are local users.  There is no guarantee that /home is a local
filesystem.  Heck, there is no guarantee that /home is even mounted
when portage is running.  Portage shouldn't be touching /home at all.
With stuff like automounted or encrypted home directories and
systemd-homed and so on it seems like it is even more important to
avoid sticking stuff in /home (and this is hardly something started by
systemd - stuff in /home that is non-static has been a thing for some
time - certainly it was happening in the 90s on some IRIX workstations
I used).

>   * With respect to user.eclass, I'm proposing that /home be treated
>     EXACTLY THE SAME as it always has been.

I'm not aware that it was ever considered good practice to stick stuff
in /home.  I suspect it just wasn't on QA's radar in the past.

>
> All I want to do is *set* a user's home directory to /home/foo.

You don't just want to "set" it.  You want to create the directory,
which is modifying the filesystem (otherwise, why have a .keepdir?).
And setting a home directory to something that doesn't exist doesn't
seem like an improvement unless it is /dev/null.

I get though that the daemon itself doesn't use the home directory,
and that you just want it for configuring other stuff it might launch.

> Spamassassin itself is a better example than amavis. We already set the
> spamd user's home directory to /home/spamd with user.eclass. We don't
> install anything there, and this works fine. If a human logs into that
> account and generates some configuration in ~/.spamassassin, then it's
> within the spirit of the FHS to have that data stored in /home.

Looks like we might have another package to deal with, and perhaps
others as well, depending on what comes out of this thread.

> Now, with GLEP 81, we get a QA warning for that, because the eclass
> installs a keepdir file there. I would like things to remain exactly as
> they are, with no QA warning. Otherwise, we have to tell users to move
> /home/spamd to /var/lib/spamd-home or something stupid like that. I can
> think of no good reason to do so.

Well, you won't get QA warnings from the tinderbox if the default home
isn't under /home.  Users who already have the home there might get
warnings at install time.  They can just ignore them.  You could
output an einfo to explain the situation to the user.  If they're fine
with /home then they can ignore the warning, and if they want to move
it they can do so.

I'll also note that GLEP 81 itself is silent on WHERE home directories
should be placed.  If some sort of definitive answer comes out of this
thread the GLEP should probably be updated to reflect this, unless
there is a better place to put it.  Seems like the fact that this
practice was undocumented in the past is part of how we got to where
we're at.

> > It seems like the straightforward solution is to stick everything in
> > /var/lib/amavis, and fix things so that everything has the right
> > permissions regardless of install order.
>
> Please stop telling people to do this. Calling chown on the live
> filesystem is rarely safe, and I already fixed one root exploit (bug
> 630836) in the amavisd-new ebuild from the last guy who tried to adjust
> wrong permissions after the fact.

That bug appears to be restricted.  Perhaps it is embargoed?  If not,
then it probably shouldn't be restricted, especially if already fixed
and GLSA'ed (and if it wasn't GLSA'ed then it isn't fixed, not that
this has anything to do with you most likely).

Portage should provide a safe mechanism to fix permissions.  Or we
should just avoid nesting user home directories inside directories
that will be written to by that user.

If this is the same hard-linking concern as with tmpfiles.d then
somebody really just needs to fix POSIX.  :)  But as a workaround just
avoiding nesting seems like the simpler solution...

Just on a side note, I'm just stating an opinion here.  I'm not in QA.
Nobody should be construing my posts as "telling people" to do
anything.  And I do realize that you're just inheriting a situation
that goes back probably quite a long time - please don't take anything
as a personal criticism.  Maybe this stuff wasn't entirely thought out
in the past, but going forward we should try to come up with the best
solution, and then try to find the most reasonable way to get from
here to there.

> > Another option is to have /var/lib/amavis/home and /var/lib/amavis/work.
>
> This is better-looking than /var/lib/amavis-home, but it's still
> violating the spirit of the FHS to avoid triggering a warning on a dummy
> file.

Do you have a more FHS-compliant suggestion?  Clearly /home isn't
particularly FHS-compliant:

/home is a fairly standard concept, but it is clearly a site-specific
filesystem. The setup will differ from host to host.
Non-login accounts created for administrative purposes often have
their home directories elsewhere.

This actually seems like a bit of an FHS gap.  IMO /var/lib is the
lesser evil here, but if there is something else more FHS-appropriate
that could work.  FHS says that users shouldn't have to touch /var/lib
to configure a daemon, but as you've pointed out this isn't about
configuring the daemon itself, but rather helpers that it might run
after the user configures it to do so.

-- 
Rich

Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

On 1/19/20 6:29 AM, Rich Freeman wrote:
> 
> Daemons are local users.  There is no guarantee that /home is a local
> filesystem.  Heck, there is no guarantee that /home is even mounted
> when portage is running.  Portage shouldn't be touching /home at all.
> With stuff like automounted or encrypted home directories and
> systemd-homed and so on it seems like it is even more important to
> avoid sticking stuff in /home (and this is hardly something started by
> systemd - stuff in /home that is non-static has been a thing for some
> time - certainly it was happening in the 90s on some IRIX workstations
> I used).

If you're sharing /home, you're also sharing users. At that point, the
daemon user is no longer local. The rest, with all due respect, is FUD.
This is a home directory for an account that a human being will log
into, where he interactively creates per-user configuration files. If
that doesn't go in /home, what does?

If you're sharing $HOME for all of your users, why wouldn't you want to
share $HOME for this user? Trying to "hide" this one particular home
directory is second-guessing the administrator.


> You don't just want to "set" it.  You want to create the directory,
> which is modifying the filesystem (otherwise, why have a .keepdir?).
> And setting a home directory to something that doesn't exist doesn't
> seem like an improvement unless it is /dev/null.
> 
> I get though that the daemon itself doesn't use the home directory,
> and that you just want it for configuring other stuff it might launch.

The keepdir is an implementation detail; that's my whole point here. I
don't need the directory (although it would be nice) and I really don't
need the keepdir file. But the GLEP eclass calls keepdir and the QA
warning flags it.

I'm leaning towards deleting the keepdir file and the directory from $D
to avoid the warning. We can tell people to create the home directory
themselves on the wiki. I don't want to selectively ignore the warning;
if it's generating false positives (I think it is), then the warning
should be fixed.

I like your /var/lib/amavis/{home,work} suggestion second-best, but the
most appropriate place for the home directory of an account that will be
used interactively by a human (even if it's also used to start a daemon)
is under /home. For example I do want to back up that home directory,
but I don't want to back up the working directory.


> That bug appears to be restricted.  Perhaps it is embargoed?  If not,
> then it probably shouldn't be restricted, especially if already fixed
> and GLSA'ed (and if it wasn't GLSA'ed then it isn't fixed, not that
> this has anything to do with you most likely).

It's embargoed because security-audit@ goes to /dev/null, but the bug is
already fixed. (If anyone can un-embargo my other 50 ancient security
bugs, just let me know who to bribe.)


> Portage should provide a safe mechanism to fix permissions.  Or we
> should just avoid nesting user home directories inside directories
> that will be written to by that user.
> 
> If this is the same hard-linking concern as with tmpfiles.d then
> somebody really just needs to fix POSIX.  :)  But as a workaround just
> avoiding nesting seems like the simpler solution...

Essentially yes, but hard links aren't the only problem. It's unsafe to
do anything as root in a user-controlled directory. POSIX can't fix
that, and that means that portage will never be able to fix permissions
(or do anything else) within a user-controlled directory safely.

Re: [gentoo-dev] GLEP81 and /home

[Rich Freeman]

On Sun, Jan 19, 2020 at 10:49 AM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> On 1/19/20 6:29 AM, Rich Freeman wrote:
> >
> > Daemons are local users.  There is no guarantee that /home is a local
> > filesystem.  Heck, there is no guarantee that /home is even mounted
> > when portage is running.  Portage shouldn't be touching /home at all.
> > With stuff like automounted or encrypted home directories and
> > systemd-homed and so on it seems like it is even more important to
> > avoid sticking stuff in /home (and this is hardly something started by
> > systemd - stuff in /home that is non-static has been a thing for some
> > time - certainly it was happening in the 90s on some IRIX workstations
> > I used).
>
> If you're sharing /home, you're also sharing users. At that point, the
> daemon user is no longer local.

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.

This is why /root is typically outside of /home as well.

> I like your /var/lib/amavis/{home,work} suggestion second-best, but the
> most appropriate place for the home directory of an account that will be
> used interactively by a human (even if it's also used to start a daemon)
> is under /home. For example I do want to back up that home directory,
> but I don't want to back up the working directory.

Honestly, since you're only using it for what amounts to configuration
it almost makes sense to put it in /etc, and back it up for that
reason.

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.

> > Portage should provide a safe mechanism to fix permissions.  Or we
> > should just avoid nesting user home directories inside directories
> > that will be written to by that user.
> >
> > If this is the same hard-linking concern as with tmpfiles.d then
> > somebody really just needs to fix POSIX.  :)  But as a workaround just
> > avoiding nesting seems like the simpler solution...
>
> Essentially yes, but hard links aren't the only problem. It's unsafe to
> do anything as root in a user-controlled directory. POSIX can't fix
> that, and that means that portage will never be able to fix permissions
> (or do anything else) within a user-controlled directory safely.

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.

Obviously if the problem had a simple solution it would have been
implemented by now.

BTW, thanks to the recent QA post I can at least point you at
documentation for your issue.  Per the article if you want to change
it the procedure is to ask QA for an exception or change in policy,
and if you don't like the answer go to Council...

https://projects.gentoo.org/qa/policy-guide/filesystem.html#installation-paths

-- 
Rich

Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

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?

Re: [gentoo-dev] GLEP81 and /home

[Rich Freeman]

On Sun, Jan 19, 2020 at 1:37 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> 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.

Sure, I completely understand that and have no issues with it.  Ditto
with having some apache module running sendmail, which has some plugin
which gpg signs emails, which requires a ~/.gnupg for the apache user.

> 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.

I imagine that most people setting up something like this would only
be sharing high-value UIDs (>1000 in our case).  There is no need for
postfix on your Gentoo box and postfix on your Debian box to have the
same UID.  You wouldn't be sshing from postfix on the one to postfix
on the other and expecting to have the same home directory contents.

> 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.

Since it is a local account, not in /home, then it would be a separate
user even if the UID is the same (or otherwise).  You'd set up amavis
on each mail server.  They might be running different distros.  They
would be using local users.

Don't get me wrong, it would be cleaner if POSIX users had a scope the
way that an OS like Windows does it, but it isn't a big deal if you
use high-numbered UIDs for shared users, and low-numbered UIDs for
local users.

> Everything is fine here, this all works and has worked for 20 years.

Sure, it works fine if you have a single host, or do nothing to share
your home directories, which I imagine is what 95% of Gentoo users do.
I doubt most Gentoo users even encrypt /home, even though this has
been standard for most of those 20 years on just about every major
distro out there.

If a user wants to put this stuff in /home we should certainly support
that, and it would work fine if the user sets up the account properly
before installing the package.  They might get a QA warning, but that
is the user's concern.

-- 
Rich

Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

On 1/19/20 2:02 PM, Rich Freeman wrote:
> 
>> 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.
> 
> I imagine that most people setting up something like this would only
> be sharing high-value UIDs (>1000 in our case).  There is no need for
> postfix on your Gentoo box and postfix on your Debian box to have the
> same UID.  You wouldn't be sshing from postfix on the one to postfix
> on the other and expecting to have the same home directory contents.
> 

You can't do that. If you're going to mount files from one system onto
another system, using only an integer <--> username mapping as your
access control mechanism, then you'd better be damn sure that those
integers and usernames match on all systems. Otherwise I might wind up
sharing /home/mjo to rich0 because the "mjo" and "rich0" groups both
have gid 1000 locally.


> Since it is a local account, not in /home, then it would be a separate
> user even if the UID is the same (or otherwise).  You'd set up amavis
> on each mail server.  They might be running different distros.  They
> would be using local users.
> 
> Don't get me wrong, it would be cleaner if POSIX users had a scope the
> way that an OS like Windows does it, but it isn't a big deal if you
> use high-numbered UIDs for shared users, and low-numbered UIDs for
> local users.

It's a huge deal. Random users/groups can access your files if the
databases don't agree. The local/remote user distinction does not exist.


>> Everything is fine here, this all works and has worked for 20 years.
> 
> Sure, it works fine if you have a single host, or do nothing to share
> your home directories, which I imagine is what 95% of Gentoo users do.
> I doubt most Gentoo users even encrypt /home, even though this has
> been standard for most of those 20 years on just about every major
> distro out there.
> 
> If a user wants to put this stuff in /home we should certainly support
> that, and it would work fine if the user sets up the account properly
> before installing the package.  They might get a QA warning, but that
> is the user's concern.

We've talked this to death. Barring any new evidence, /home still seems
like the best place for these, and I don't want to put them in the wrong
spot (forcing users to migrate) just to appease a QA warning from before
GLEP81 was a thing.

Re: [gentoo-dev] GLEP81 and /home

[Rich Freeman]

On Sun, Jan 19, 2020 at 2:27 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> On 1/19/20 2:02 PM, Rich Freeman wrote:
> >
> >> 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.
> >
> > I imagine that most people setting up something like this would only
> > be sharing high-value UIDs (>1000 in our case).  There is no need for
> > postfix on your Gentoo box and postfix on your Debian box to have the
> > same UID.  You wouldn't be sshing from postfix on the one to postfix
> > on the other and expecting to have the same home directory contents.
> >
>
> You can't do that. If you're going to mount files from one system onto
> another system, using only an integer <--> username mapping as your
> access control mechanism, then you'd better be damn sure that those
> integers and usernames match on all systems. Otherwise I might wind up
> sharing /home/mjo to rich0 because the "mjo" and "rich0" groups both
> have gid 1000 locally.

Obviously the UIDs associated with the shared /home need to be
identical.  Simplest solution is to sync anything > 1000 in
/etc/passwd, and then not allow UIDs below 1000 in /home.  A cron job
could easily handle both, and of course regular users can't go
creating stuff with the wrong UID anyway.

> We've talked this to death. Barring any new evidence, /home still seems
> like the best place for these, and I don't want to put them in the wrong
> spot (forcing users to migrate) just to appease a QA warning from before
> GLEP81 was a thing.

Well, great, then by all means ask QA for a policy exception.  Not my
place to yell at you if you don't, but don't be surprised if somebody
else does...

-- 
Rich

Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

On 1/19/20 2:47 PM, Rich Freeman wrote:
> 
> Obviously the UIDs associated with the shared /home need to be
> identical.  Simplest solution is to sync anything > 1000 in
> /etc/passwd, and then not allow UIDs below 1000 in /home.  A cron job
> could easily handle both, and of course regular users can't go
> creating stuff with the wrong UID anyway.

That's not enough. You also need to sync any user/group that appears as
the owner or group of a file in /home, and every user/group that appears
in an ACL in /home, and so on. And since you have no idea what files or
access control lists will show up in /home, you'd better sync them all.


>> We've talked this to death. Barring any new evidence, /home still seems
>> like the best place for these, and I don't want to put them in the wrong
>> spot (forcing users to migrate) just to appease a QA warning from before
>> GLEP81 was a thing.
> 
> Well, great, then by all means ask QA for a policy exception.  Not my
> place to yell at you if you don't, but don't be surprised if somebody
> else does...
> 

I'm not going to violate the policy, I'm going to delete the keepdir
file from $D. Then everything is back to normal.

If I was willing to introduce a QA warning, this thread would have been
a lot shorter =P

Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

On 1/19/20 4:00 PM, Michael Orlitzky wrote:
> 
> If I was willing to introduce a QA warning, this thread would have been
> a lot shorter =P
> 

Just kidding, the eclass is rigged to die in src_install if you delete
the home directory, and if you wait until pkg_preinst, the warning gets
shown anyway (for a file that's not there, noice).

Guess we'll be triggering a warning after all.

Re: [gentoo-dev] GLEP81 and /home

[Rich Freeman]

On Sun, Jan 19, 2020 at 4:00 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> On 1/19/20 2:47 PM, Rich Freeman wrote:
> >
> > Obviously the UIDs associated with the shared /home need to be
> > identical.  Simplest solution is to sync anything > 1000 in
> > /etc/passwd, and then not allow UIDs below 1000 in /home.  A cron job
> > could easily handle both, and of course regular users can't go
> > creating stuff with the wrong UID anyway.
>
> That's not enough. You also need to sync any user/group that appears as
> the owner or group of a file in /home, and every user/group that appears
> in an ACL in /home, and so on. And since you have no idea what files or
> access control lists will show up in /home, you'd better sync them all.

That doesn't seem reasonable, considering that this could require
syncing across various Distros, or even various Unix-like OSes.
It would be far simpler for the sysadmin to simply ensure that no
unsynced user owns a file or appears in an ACL.  That would be pretty
trivial to achieve.  Whatever is hosting /home could be designed to
block such changes, or you could just scan for these ownership issues
periodically and treat those responsible for them appropriately.

In any case, maintaining permissions on stuff in /home is a sysadmin
responsibility, not a distro responsibility.

On Sun, Jan 19, 2020 at 5:09 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> Just kidding, the eclass is rigged to die in src_install if you delete
> the home directory, and if you wait until pkg_preinst, the warning gets
> shown anyway (for a file that's not there, noice).
>
> Guess we'll be triggering a warning after all.

On the topic of treating those responsible appropriately, somehow I
could see this scenario turning into a quiz question.

I mean, would it kill you to just talk to QA first?

-- 
Rich

Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

On 1/19/20 8:20 PM, Rich Freeman wrote:
> It would be far simpler for the sysadmin to simply ensure that no
> unsynced user owns a file or appears in an ACL.  That would be pretty
> trivial to achieve.  Whatever is hosting /home could be designed to
> block such changes, or you could just scan for these ownership issues
> periodically and treat those responsible for them appropriately.

Fantasy scenarios again. I'm not going to debunk a system that you just
thought up and that has never existed. Why don't you find one person who
actually does this, and see if it bothers him if we create a home
directory under /home where it belongs?


> On the topic of treating those responsible appropriately, somehow I
> could see this scenario turning into a quiz question.
> 
> I mean, would it kill you to just talk to QA first?

I've already got responses from two QA members. This thread is pretty
hard to miss. I'm working on a patch for the install-qa-check.d check
and I'm sure I'll get more when I post it.

Re: [gentoo-dev] GLEP81 and /home

[Rich Freeman]

On Sun, Jan 19, 2020 at 8:51 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> On 1/19/20 8:20 PM, Rich Freeman wrote:
> > It would be far simpler for the sysadmin to simply ensure that no
> > unsynced user owns a file or appears in an ACL.  That would be pretty
> > trivial to achieve.  Whatever is hosting /home could be designed to
> > block such changes, or you could just scan for these ownership issues
> > periodically and treat those responsible for them appropriately.
>
> Fantasy scenarios again. I'm not going to debunk a system that you just
> thought up and that has never existed. Why don't you find one person who
> actually does this, and see if it bothers him if we create a home
> directory under /home where it belongs?

Uh, I'm pretty confident that nothing in my /home is owned by a UID
under 1000, or has an ACL referencing such a UID.  I just checked with
myself and I don't want you creating directories in /home.

This really seems like it has the potential to create a mess for
anybody using LUKS-encrypted home directories, stuff mounted from
CIFS, and so on.  While I personally don't do either it seems fairly
mainstream, and I could eventually see myself using it more once
better supported on Gentoo (such as when systemd-homed is more
mainstream).

> > On the topic of treating those responsible appropriately, somehow I
> > could see this scenario turning into a quiz question.
> >
> > I mean, would it kill you to just talk to QA first?
>
> I've already got responses from two QA members. This thread is pretty
> hard to miss.

Well, then why go posting stuff like "guess we'll be triggering a
warning after all?"

> I'm working on a patch for the install-qa-check.d check
> and I'm sure I'll get more when I post it.

Are you just allowing it to not create the directory, or are we
considering patching it to allow creating stuff under /home?  It would
seem that the policy would also need updating in that case, but
probably not the former.

-- 
Rich

Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

On 1/19/20 9:52 PM, Rich Freeman wrote:
>>
>> Fantasy scenarios again. I'm not going to debunk a system that you just
>> thought up and that has never existed. Why don't you find one person who
>> actually does this, and see if it bothers him if we create a home
>> directory under /home where it belongs?
> 
> Uh, I'm pretty confident that nothing in my /home is owned by a UID
> under 1000, or has an ACL referencing such a UID.  I just checked with
> myself and I don't want you creating directories in /home.

This is retarded, stop wasting my time.


>>>
>>> I mean, would it kill you to just talk to QA first?
>>
>> I've already got responses from two QA members. This thread is pretty
>> hard to miss.
> 
> Well, then why go posting stuff like "guess we'll be triggering a
> warning after all?"

If these two things are logically connected, I don't see it.


> 
>> I'm working on a patch for the install-qa-check.d check
>> and I'm sure I'll get more when I post it.
> 
> Are you just allowing it to not create the directory, or are we
> considering patching it to allow creating stuff under /home?  It would
> seem that the policy would also need updating in that case, but
> probably not the former.
> 

The patch will make an exception for acct-user packages only; for /home,
/home/${PN}, and /home/${PN}/.keep*. In other words, it makes things
work exactly how they did before the GLEP81 eclass started keepdir'ing
the home directory.

Re: [gentoo-dev] GLEP81 and /home

[Rich Freeman]

On Sun, Jan 19, 2020 at 10:16 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>
> This is retarded, stop wasting my time.
>

There is nothing retarded about shared /home directories.  They're
pretty common in the real world.

> >> I've already got responses from two QA members. This thread is pretty
> >> hard to miss.
> >
> > Well, then why go posting stuff like "guess we'll be triggering a
> > warning after all?"
>
> If these two things are logically connected, I don't see it.

If you're working with QA to change the QA checks, then you won't be
triggering warnings.

> >> I'm working on a patch for the install-qa-check.d check
> >> and I'm sure I'll get more when I post it.
> >
> > Are you just allowing it to not create the directory, or are we
> > considering patching it to allow creating stuff under /home?  It would
> > seem that the policy would also need updating in that case, but
> > probably not the former.
>
> The patch will make an exception for acct-user packages only; for /home,
> /home/${PN}, and /home/${PN}/.keep*. In other words, it makes things
> work exactly how they did before the GLEP81 eclass started keepdir'ing
> the home directory.

IMO this isn't the right direction to go in, but we can always put it
on the council agenda.  Maintaining the status quo (pre-QA-check) in
the interim isn't unreasonable, nor is keeping your package behavior
as it is for now.  Obviously this issue has been around for some time.
I realize that you didn't invent it.

I guess this is the sort of thing that people will tend to disagree
on.  At least Gentoo doesn't force this nonsense down my throat.  :)

-- 
Rich

Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

On 1/19/20 10:40 PM, Rich Freeman wrote:
> On Sun, Jan 19, 2020 at 10:16 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>>
>> This is retarded, stop wasting my time.
>>
> 
> There is nothing retarded about shared /home directories.  They're
> pretty common in the real world.
> 

What's retarded is copy/pasting words from last week's buzzword bingo as
if they're valid reasons to not use /home for home directories.

LUKS is a thing, but you don't use it. CIFS is a thing, but you don't
use it. Shared home directories are a thing, but you don't use it. Give
me one real example of how any of these things cause a problem and I'll
change my stance. I don't have a special emotional attachment to /home.
I think it's where this stuff should go because (a) home directories are
what /home is for, and (b) it doesn't cause any other problems. If (b)
isn't true, you win.

Re: [gentoo-dev] GLEP81 and /home

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

On Sun, Jan 19, 2020 at 10:49:10AM -0500, Michael Orlitzky wrote:
> > That bug appears to be restricted.  Perhaps it is embargoed?  If not,
> > then it probably shouldn't be restricted, especially if already fixed
> > and GLSA'ed (and if it wasn't GLSA'ed then it isn't fixed, not that
> > this has anything to do with you most likely).
> It's embargoed because security-audit@ goes to /dev/null, but the bug is
> already fixed. (If anyone can un-embargo my other 50 ancient security
> bugs, just let me know who to bribe.)
Please file a bug to infra with the list of old security embargoed bugs,
and we can help you get them fixed (probably by helping you review them
first).

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

Re: [gentoo-dev] GLEP81 and /home

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 3032 bytes --]

On Sat, Jan 18, 2020 at 6:50 PM Michael Orlitzky <mjo@gentoo.org> wrote:

> On 1/18/20 7:21 PM, Rich Freeman wrote:
> > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky <mjo@gentoo.org> wrote:
> >>
> >> But now users have to follow one more step (create /home/amavis) when
> >> setting up amavisd-new. Is the QA check really assuring a quality user
> >> experience here?
> >>
> >
> > Lots of daemons need a home directory for their users, and usually
> > they manage to get by in /var/lib.  It really seems like a bad
> > practice to start having packages creating stuff in /home.  Certainly
> > I don't want random daemons sticking stuff in /home, which I manage
> >
>
> Let's restart:
>
>   * The daemon DOES NOT need a home directory for its user.
>   * I DO NOT want to install anything to anyone's home directory.
>   * With respect to user.eclass, I'm proposing that /home be treated
>     EXACTLY THE SAME as it always has been.
>
> All I want to do is *set* a user's home directory to /home/foo.
>

Why wouldn't you set the homedirectory to /dev/null then?

-A


>
> Some people want to configure amavis to launch a program like pyzor,
> which uses per-user configuration files. If you want to do that, you
> first log in as amavis, and run some command like
>
>   $ pyzor discover
>
> which then finds some servers and creates configuration files for you in
> $HOME/.pyzor.
>
> This is user configuration, not daemon configuration. It doesn't belong
> in the daemon's working directory. In particular, you should not be
> dicking around in the daemon's working directory when you run "su
> amavis..." because what you're doing is irrelevant to the daemon.
>
> Spamassassin itself is a better example than amavis. We already set the
> spamd user's home directory to /home/spamd with user.eclass. We don't
> install anything there, and this works fine. If a human logs into that
> account and generates some configuration in ~/.spamassassin, then it's
> within the spirit of the FHS to have that data stored in /home.
>
> Now, with GLEP 81, we get a QA warning for that, because the eclass
> installs a keepdir file there. I would like things to remain exactly as
> they are, with no QA warning. Otherwise, we have to tell users to move
> /home/spamd to /var/lib/spamd-home or something stupid like that. I can
> think of no good reason to do so.
>
>
> > It seems like the straightforward solution is to stick everything in
> > /var/lib/amavis, and fix things so that everything has the right
> > permissions regardless of install order.
>
> Please stop telling people to do this. Calling chown on the live
> filesystem is rarely safe, and I already fixed one root exploit (bug
> 630836) in the amavisd-new ebuild from the last guy who tried to adjust
> wrong permissions after the fact.
>
>
> > Another option is to have /var/lib/amavis/home and /var/lib/amavis/work.
>
> This is better-looking than /var/lib/amavis-home, but it's still
> violating the spirit of the FHS to avoid triggering a warning on a dummy
> file.
>
>

[-- Attachment #2: Type: text/html, Size: 3933 bytes --]

Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

On 1/19/20 2:19 PM, Alec Warner wrote:
> 
>     All I want to do is *set* a user's home directory to /home/foo.
> 
> Why wouldn't you set the homedirectory to /dev/null then?
> 

Because /dev/null is not /home/foo? Is this a trick question? =)

Re: [gentoo-dev] GLEP81 and /home

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On Sun, Jan 19, 2020 at 11:28 AM Michael Orlitzky <mjo@gentoo.org> wrote:

> On 1/19/20 2:19 PM, Alec Warner wrote:
> >
> >     All I want to do is *set* a user's home directory to /home/foo.
> >
> > Why wouldn't you set the homedirectory to /dev/null then?
> >
>
> Because /dev/null is not /home/foo? Is this a trick question? =)
>
>
 Ahh quoting, I'll try with more context ;)

Earlier you wrote:
----
 * The daemon DOES NOT need a home directory for its user.
  * I DO NOT want to install anything to anyone's home directory.
  * With respect to user.eclass, I'm proposing that /home be treated
    EXACTLY THE SAME as it always has been.
---

So my question is "why not leave the homedir unset, or set it to /dev/null?"
The claim is that the daemon doesn't need a home directory, so why are we
trying to make one?

-A

[-- Attachment #2: Type: text/html, Size: 1357 bytes --]

Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

On 1/19/20 2:32 PM, Alec Warner wrote:
> 
> Earlier you wrote:
> ----
>  * The daemon DOES NOT need a home directory for its user.
>   * I DO NOT want to install anything to anyone's home directory.
>   * With respect to user.eclass, I'm proposing that /home be treated
>     EXACTLY THE SAME as it always has been.
> ---
> 
> So my question is "why not leave the homedir unset, or set it to /dev/null?"
> The claim is that the daemon doesn't need a home directory, so why are
> we trying to make one?
> 

Ah, good question. As the de facto no-homedir police, even I think this
case warrants an exception. Technically, the daemon's user does not need
a home directory. But almost everyone that uses amavis will want to
combine it with one of these programs that looks in $HOME.

We could install the user with no homedir, and make the people who need
it override the acct-user ebuild in an overlay, but that's a pain in the
butt. Since the common case will utilize a home directory, I'd rather
pick one decent location upstream, and not have 99% of users define one
ad-hoc in an overlay.

The reason I'm being so annoying is because it's important to get the
location right. Every time the user package is reinstalled, its homedir
gets reset. So it's non-trivial to override, and can't really be changed
in an ebuild (usermod fails if the user is running a process).

Re: [gentoo-dev] GLEP81 and /home

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 3784 bytes --]

On Sat, Jan 18, 2020 at 9:52 AM Michael Orlitzky <mjo@gentoo.org> wrote:

> We forbid packages from installing to /home for good reason: for most of
> history, users (and their home directories) were outside the purview of
> the package manager. But with GLEP81, that's changed: the package
> manager is now in charge of creating each system user's home directory
> and of giving it the correct permissions and ownership.
>
> Is the policy against installing to /home still consistent?
>
> For example: the mail-filter/amavisd-new daemon needs a user, typically
> called "amavis". The daemon also needs a working directory that it can
> write to. The obvious choice for a working directory is /var/lib/amavis,
> but there's a catch: spamassassin, razor, pyzor, et cetera (which are
> all used by amavis) store their configuration in the current user's home
> directory, and not in some daemon-specific location. So "amavis" needs a
> home directory, because that's where much of the configuration for
> amavisd goes.
>
> Where do we put amavis's home directory?
>
>   1 /var/lib/amavis is a bad idea, because it conflicts with the working
>     directory (we don't want the two packages to get out of sync, nor do
>     we want to keep them in-sync manually).
>
>   2 /var/lib/amavis/home was my next choice, because logically it puts
>     the amavisd configuration in a subdirectory of the place where all
>     of the other amavis stuff goes, and because it doesn't have the
>     same issue that (1) does.
>
>     But there's a problem: if we create /var/lib/amavis/home before
>     amavisd-new is installed (as happens when you emerge amavisd-new),
>     then /var/lib/amavis winds up root:root and the installation of
>     amavisd-new doesn't change that. So now amavisd-new doesn't work,
>     because it can't write to its working directory.
>
>     This is a combination of an implementation detail and the fact that
>     the PMS doesn't cover directories; but ultimately, it just doesn't
>     work reliably.
>
>   3 /home/amavis also seems fine to me, except for the fact that it's a
>     QA violation to install there.
>
> Note that we could always set system users' home directories to
> /home/whatever. It has only become a QA violation with GLEP81 because
> the eclass calls keepdir on the user's home directory.
>
> Should option (3) be viable, or do I go back to the drawing board?
>

I tend to agree that in theory keeping the working directory and home
directory the same is not ideal. However  I'm not really aware of any
practical problems. Haven't we basically run in this configuration for
years? What kind of issues does it pose (outside of "well it sounds like
not the best idea?")

Agreeing with ulm here. I think the potential struggle for (3) is that
conceptually /home is not always system specific. If /home is shared, you
could end up with a bad time (e.g. I *don't* want /home/amavis shared
across all my hosts, how would I manage multiple versions? Multiple
configs?) Often all of /home is mounted and it becomes tricky to build
workarounds. You could do things like "symlink /home/amavisd to some local
path". At work we use /usr/local/google/home/$USER for this purpose; but it
is basically a vestigial artifact from an earlier time than something we
explicitly designed.

Even the symlink solution is not ideal. NFS can present some exciting
reliability issues and so having to touch NFS just to read the symlink
(pointing locally) is probably not something I'd advise at scale; it would
be simpler to change the users homedir to be elsewhere. Note that I'd
expect large scale installs to do this anyway (I wouldn't rely on GLEP81 to
manage users in an enterprise environment) but i'm not sure if the entire
community shares that belief ;)

-A

[-- Attachment #2: Type: text/html, Size: 4518 bytes --]

Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

On 1/18/20 2:03 PM, Alec Warner wrote:
> 
> I tend to agree that in theory keeping the working directory and home
> directory the same is not ideal. However  I'm not really aware of any
> practical problems. Haven't we basically run in this configuration for
> years? What kind of issues does it pose (outside of "well it sounds like
> not the best idea?")

There have been numerous bugs and mailing list discussions about the
problems it causes, but it's kind of a moot point here. The best reason
to avoid re-using /var/lib/amavis as the daemon's home directory is
because it really is treated like a home directory by all of these
packages, and we shouldn't dump a user's dotfiles into a daemon's
working directory without a good reason.

(We haven't been running this configuration for years, because we
haven't had the GLEP81 eclasses that clobber your permissions for years.)


> Agreeing with ulm here. I think the potential struggle for (3) is that
> conceptually /home is not always system specific. If /home is shared,
> you could end up with a bad time (e.g. I *don't* want /home/amavis
> shared across all my hosts, how would I manage multiple versions?

All of the upstream packages treat $HOME as user configuration. If you
want to run two different daemons with two different configurations and
if those configurations are sourced from $HOME, then you make two
different users. There is no problem here.

I'm willing to pick something like /var/lib/amavis-home, but that's
clearly just second-guessing the administrator and putting a home
directory somewhere it doesn't belong to avoid a QA warning.

We have a similar situation with spamd in spamassassin itself, and I'd
rather not maintain my own fake /home hierarchy as /var/lib/$user-home.

Re: [gentoo-dev] GLEP81 and /home

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]

On Sat, 2020-01-18 at 12:51 -0500, Michael Orlitzky wrote:
> We forbid packages from installing to /home for good reason: for most of
> history, users (and their home directories) were outside the purview of
> the package manager. But with GLEP81, that's changed: the package
> manager is now in charge of creating each system user's home directory
> and of giving it the correct permissions and ownership.
> 
> Is the policy against installing to /home still consistent?
> 
> For example: the mail-filter/amavisd-new daemon needs a user, typically
> called "amavis". The daemon also needs a working directory that it can
> write to. The obvious choice for a working directory is /var/lib/amavis,
> but there's a catch: spamassassin, razor, pyzor, et cetera (which are
> all used by amavis) store their configuration in the current user's home
> directory, and not in some daemon-specific location. So "amavis" needs a
> home directory, because that's where much of the configuration for
> amavisd goes.
> 
> Where do we put amavis's home directory?
> 
>   1 /var/lib/amavis is a bad idea, because it conflicts with the working
>     directory (we don't want the two packages to get out of sync, nor do
>     we want to keep them in-sync manually).
> 

Sounds like you've created an arbitrary rule that prevents the two
packages from using the same directory, and therefore you've created
this problem yourself.  Why not just go back and reconsider using
the same directory instead of adding complexity for ideological reasons?

Is it really that problematic to have the directory created by amavisd
user, and have all packages depend on it?

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky]

On 1/18/20 2:08 PM, Michał Górny wrote:
> 
> Sounds like you've created an arbitrary rule that prevents the two
> packages from using the same directory, and therefore you've created
> this problem yourself.  Why not just go back and reconsider using
> the same directory instead of adding complexity for ideological reasons?
> 
> Is it really that problematic to have the directory created by amavisd
> user, and have all packages depend on it?
> 

The user's home directory is conceptually and (usually) literally
separate from the daemon's working directory. That's upstream, not in my
head. So it's wrong to combine them in principle, especially given that
it creates security timebombs when two packages "share" a directory.