GLEP81 and /home

GLEP81 and /home

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.

Re: GLEP81 and /home

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 ;)

Re: GLEP81 and /home

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

Re: GLEP81 and /home

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.

Re: GLEP81 and /home

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: GLEP81 and /home

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?

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.

Re: GLEP81 and /home

On 1/18/20 7:21 PM, Rich Freeman wrote:

> On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky <[hidden email]> 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: GLEP81 and /home

>
> On 1/18/20 7:21 PM, Rich Freeman wrote:
> > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky <[hidden email]> 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.

Re: GLEP81 and /home

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: GLEP81 and /home

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

Re: GLEP81 and /home

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: GLEP81 and /home

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

Re: GLEP81 and /home

On 1/18/20 7:21 PM, Rich Freeman wrote:
> On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky <[hidden email]> 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.

Re: GLEP81 and /home

>
>> 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: GLEP81 and /home

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?

Re: GLEP81 and /home

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

Re: GLEP81 and /home

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