public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alec Warner <antarus@gentoo.org>
To: Gentoo Dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home
Date: Mon, 20 Jan 2020 14:08:58 -0800	[thread overview]
Message-ID: <CAAr7Pr9czBqdiVPo9J2hySrr8HzuUKq05STCgzuJY13fZTYjwA@mail.gmail.com> (raw)
In-Reply-To: <d3732f3e-046c-f56f-b6e4-5cbec73797df@gentoo.org>

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

On Mon, Jan 20, 2020 at 6:20 AM Michael Orlitzky <mjo@gentoo.org> wrote:

> On 1/20/20 2:02 AM, Ulrich Mueller wrote:
> >>>>>> On Mon, 20 Jan 2020, Michael Orlitzky wrote:
> >
> >>   install-qa-check.d: allow acct-user home directories under /home.
> >
> > Nope. As you've been told, /home is site specific and can be setup in
> > multiple ways that are incompatible with the package manager installing
> > things there (the only exception being baselayout creating the directory
> > itself).
>
> I haven't been given a single technical reason why using /home would
> cause a problem. What specific incompatibilities are you talking about?
>

So I can describe in detail one example, but its not running Gentoo; so I'm
not sure if you care in practice.

At work we had sec=krb5 NFS v3 mounted home directories. They were mounted
in /home (via the automounter.) So if these machines ran Gentoo and you
went to do something like "create /home/amavisd" it would fail because the
root user doesn't have the ability to make home directories in /home (uid=0
is mapped to nobody, who doesn't have +w on /home.) All home directories
were created by a business application and there were specific hosts where
root was not squashed (and we used sec=sys instead of krb5) and so root on
the admin host would have +w on /home and not be squashed to nobody.)

In practice in that enterprise environment, if we needed something like
/home/web/ (which I think did exist at one point) we would create a role
account in LDAP (www-data is a common user for example), assign it a uid,
create the homedirectory (/home/web) and it would be owned by
www-data:www-data. Then we would configure the web front ends to use
www-data instead of the normal user (apache or nginx or whatever.)

In practice:
(1) These environments are what I'd consider legacy; if I was crafting an
enterprise environment today I would not design one quite like this[0].
(2) I don't think most people running Gentoo are running these
environments, which is why you don't see many practical objections on the
list. I think it's reasonable to avoid service account homedirs in /home
not because of fancy examples like above (that maybe 10 companies in the
world run) and instead just focus on this idea that "system stuff doesn't
go in /home." Its somewhat arbitrary as mgorny points out earlier in the
thread.

-A

[0] Linux has really poor machine trust by default and while you can build
a ragtag set of primitives to trust machines and identities; I think the
effort is better spent shelling out money for some kind of real identity
management provider that isn't just 'hey here is a uid + ip' which is how
we did things in the 90s man. It was an innocent time ;)



>
> > Quoting FHS-3.0 again:
> >
> > | On large systems (especially when the /home directories are shared
> > | amongst many hosts using NFS) it is useful to subdivide user home
> > | directories. Subdivision may be accomplished by using subdirectories
> > | such as /home/staff, /home/guests, /home/students, etc.
> >
> > So, how are you going to detect if such a scheme is used on the system,
> > and in which subdirectory the amavis user should be placed?
>
> The same way we detect that scheme before setting a home directory to
> /var/lib/whatever, which you may notice, is not under /home/guests or
> anything like that. Does this cause a real technical problem, or is it
> just more FUD?
>
>
> > I also wonder why you would send this patch, when there wasn't a single
> > voice supporting your proposition in the other thread and several
> > opposing ones.
>
> I don't want to just complain without offering a solution.
>
> No one has pointed out any problems with it.
>
> This stuff is already in /home, and I'd like to get off user.eclass
> without introducing a new QA warning for a keepdir file.
>
>

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

  parent reply	other threads:[~2020-01-20 22:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-20  3:43 [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home Michael Orlitzky
2020-01-20  3:43 ` [gentoo-dev] [PATCH 1/2] install-qa-check.d: disallow "nix" and "gnu" as top-level paths Michael Orlitzky
2020-01-20  5:33   ` Michał Górny
2020-01-20  3:43 ` [gentoo-dev] [PATCH 2/2] install-qa-check.d: allow acct-user home directories under /home Michael Orlitzky
2020-01-20  5:35   ` Michał Górny
2020-01-20 23:57   ` Andreas K. Huettel
2020-01-21  0:22     ` Michael Orlitzky
2020-01-21  5:25       ` Michał Górny
2020-01-20  7:02 ` [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home Ulrich Mueller
2020-01-20 14:20   ` Michael Orlitzky
2020-01-20 14:50     ` David Seifert
2020-01-20 15:20       ` Michael Orlitzky
2020-01-20 18:39         ` Michał Górny
2020-01-20 18:52           ` Michael Orlitzky
2020-01-20 18:01     ` Ulrich Mueller
2020-01-20 18:15       ` Michael Orlitzky
2020-01-20 22:08     ` Alec Warner [this message]
2020-01-20 23:07       ` Michael Orlitzky
2020-01-21 18:24         ` Robin H. Johnson
2020-01-21 11:44     ` Jaco Kroon
2020-01-21 14:57       ` 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=CAAr7Pr9czBqdiVPo9J2hySrr8HzuUKq05STCgzuJY13fZTYjwA@mail.gmail.com \
    --to=antarus@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