Re: [gentoo-dev] GLEP81 and /home

[Michael Orlitzky <mjo@gentoo.org>]

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.