From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 39653138350 for ; Mon, 20 Jan 2020 22:09:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F21A0E08AB; Mon, 20 Jan 2020 22:09:10 +0000 (UTC) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 46F6BE089D for ; Mon, 20 Jan 2020 22:09:10 +0000 (UTC) Received: by mail-io1-xd43.google.com with SMTP id z193so696406iof.1 for ; Mon, 20 Jan 2020 14:09:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gentoo-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5pRaO5CD4B1SVxotKtfTBuQVz31/d7akrvPobd/yitU=; b=qGM250lsRKoKdTFT6C83/O4rxp1BxOzGTmXtsm6Lq/I9d9YFw4HjkQoUnmZy7ZCzst q5VhFmVbyClwVhosENsvh2lB+cm5QenJ3oFNht3W2StvSx+0kcQoZCUZCfxopRfVhc29 XF6ivVMp+sDi10gtjZC2PMb7gjDRRKetQlwaFbbnGj3SQsjLCyO4fA+SPYf5Ay2JKz27 LmqGgZn1yyksPVKVeEuv3ErhEg5FP/uuqasPwH03e2KWvh8iK5nkHBXanq7XPqy4m3fd 5O0AS857hnxKg59Il5V9KP2rQG9A1BfsW46a145J3znGWfIHsOm9J9V4pQIPy55GKmDN hZNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5pRaO5CD4B1SVxotKtfTBuQVz31/d7akrvPobd/yitU=; b=euKzL6yk+ECgTtg8KVIUC9QRTO38vUb0wEED1rA/kny03zAZFP5Yz46H6vl6AJ/XM+ 5BfG3JocZiGGqd4OILM7FY1jRtiNzwZLgOgBeq47xiQNLDj+BkmgF5QHQw2LPIThx7oi 9ONhEtddgyx9xfrAKSXOmd8P/uV2YDUKlm0R7j010csQjDSZd4XUuShzlcnD8AOU02DL 10b4FNwPcE+yfBFi/9prXcZftBMHdm49rYiKeeFYJWx2BOklS5+/+tthNNn9zzuFdL+Q nH5hgrydcYgvsQExEhc5i+uH2vOs7dlxNaZsbov5My6bBJy+j/2wNUeePt9AVIPHkfSL xhFA== X-Gm-Message-State: APjAAAVlBNrdtxgVo1jSzh9UpXMxdD1G16EGgGqWZECOI2s2Y5ZYSAhi MU7gqs9RERr2g8ZIFuVvuVxh+YSKPyC50dHdGJGCAPh3zy0= X-Google-Smtp-Source: APXvYqwZjGk1IA2sFz/AvLD2wDj3cYq8ikiFnWLKE8POrraTlNWy2rNNpE2KkjMjAdKph/qcFck14BcnLIIQSwbYAcg= X-Received: by 2002:a05:6602:2591:: with SMTP id p17mr867277ioo.38.1579558149037; Mon, 20 Jan 2020 14:09:09 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20200120034350.27108-1-mjo@gentoo.org> In-Reply-To: From: Alec Warner Date: Mon, 20 Jan 2020 14:08:58 -0800 Message-ID: Subject: Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home To: Gentoo Dev Content-Type: multipart/alternative; boundary="0000000000006047b4059c998a5d" X-Archives-Salt: 3aa48f4b-cf02-422b-8c62-940a746fb84a X-Archives-Hash: f86e30ffd6957806d9bf45bdff42e586 --0000000000006047b4059c998a5d Content-Type: text/plain; charset="UTF-8" On Mon, Jan 20, 2020 at 6:20 AM Michael Orlitzky 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. > > --0000000000006047b4059c998a5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 20, 2020 at 6:20 AM Micha= el Orlitzky <mjo@gentoo.org> wr= ote:
On 1/20/20 = 2:02 AM, Ulrich Mueller wrote:
>>>>>> On Mon, 20 Jan 2020, Michael Orlitzky wrote:
>
>>=C2=A0 =C2=A0install-qa-check.d: allow acct-user home directories u= nder /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 installin= g
> things there (the only exception being baselayout creating the directo= ry
> 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, b= ut its not running Gentoo; so I'm not sure if you care in practice.

At work we had sec=3Dkrb5 NFS v3 mounted home directo= ries. They were mounted in /home (via the automounter.) So if these machine= s ran Gentoo and you went to do something like "create /home/amavisd&q= uot; it would fail because the root user doesn't have the ability to ma= ke home directories in /home (uid=3D0 is mapped to nobody, who doesn't = have=C2=A0+w on /home.) All home directories were created by a business app= lication and there were specific hosts where root was not squashed (and we = used sec=3Dsys instead of krb5) and so root on the admin host would have=C2= =A0+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 th= e homedirectory=C2=A0(/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 pra= ctice:
(1) These environments are what I'd consider legac= y; 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 Ge= ntoo are running these environments, which is why you don't see many pr= actical objections on the list. I think it's=C2=A0reasonable to avoid s= ervice 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 id= ea that "system stuff doesn't go in /home." Its somewhat arbi= trary as mgorny points out earlier in the thread.

= -A

[0] Linux has really poor machine trust by defa= ult and while you can build a ragtag set of primitives to trust machines an= d identities; I think the effort is better spent shelling out money for som= e kind of real identity management provider that isn't just 'hey he= re is a uid=C2=A0+ ip' which is how we did things in the 90s man. It wa= s 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 s= ingle
> 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.

--0000000000006047b4059c998a5d--