On Mon, Jan 20, 2020 at 6:20 AM Michael Orlitzky <m...@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. > >
