public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] GLEP81 and /home
Date: Sun, 19 Jan 2020 12:42:34 -0500	[thread overview]
Message-ID: <CAGfcS_kAwXUY1mTcqtAhsp0wS+r3SMjc2W43TrO_ON2CqnJA2g@mail.gmail.com> (raw)
In-Reply-To: <2313c928-6c17-394c-d437-b5ad1f76ecea@gentoo.org>

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


  reply	other threads:[~2020-01-19 17:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-18 17:51 [gentoo-dev] GLEP81 and /home Michael Orlitzky
2020-01-18 18:10 ` Ulrich Mueller
2020-01-18 23:38   ` Michael Orlitzky
2020-01-19  0:21     ` Rich Freeman
2020-01-19  2:50       ` Michael Orlitzky
2020-01-19 11:29         ` Rich Freeman
2020-01-19 15:49           ` Michael Orlitzky
2020-01-19 17:42             ` Rich Freeman [this message]
2020-01-19 18:37               ` Michael Orlitzky
2020-01-19 19:02                 ` Rich Freeman
2020-01-19 19:27                   ` Michael Orlitzky
2020-01-19 19:47                     ` Rich Freeman
2020-01-19 21:00                       ` Michael Orlitzky
2020-01-19 22:09                         ` Michael Orlitzky
2020-01-20  1:20                         ` Rich Freeman
2020-01-20  1:51                           ` Michael Orlitzky
2020-01-20  2:52                             ` Rich Freeman
2020-01-20  3:16                               ` Michael Orlitzky
2020-01-20  3:40                                 ` Rich Freeman
2020-01-20  3:57                                   ` Michael Orlitzky
2020-01-19 19:37             ` Robin H. Johnson
2020-01-19 19:19         ` Alec Warner
2020-01-19 19:28           ` Michael Orlitzky
2020-01-19 19:32             ` Alec Warner
2020-01-19 20:44               ` Michael Orlitzky
2020-01-18 19:03 ` Alec Warner
2020-01-18 20:16   ` Michael Orlitzky
2020-01-18 19:08 ` Michał Górny
2020-01-18 19:44   ` Michael Orlitzky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGfcS_kAwXUY1mTcqtAhsp0wS+r3SMjc2W43TrO_ON2CqnJA2g@mail.gmail.com \
    --to=rich0@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox