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 4ACF2138350 for ; Sat, 18 Jan 2020 17:52:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 58033E08E0; Sat, 18 Jan 2020 17:52:01 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 0BBD8E08D1 for ; Sat, 18 Jan 2020 17:52:00 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id 9FC3534E1B3 for ; Sat, 18 Jan 2020 17:51:59 +0000 (UTC) To: gentoo-dev@lists.gentoo.org From: Michael Orlitzky Subject: [gentoo-dev] GLEP81 and /home Message-ID: <825bd707-faa2-f956-edbb-a11a8d82296b@gentoo.org> Date: Sat, 18 Jan 2020 12:51:50 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 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 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: 456cebe0-f016-4395-b24d-a69c3f7e3b49 X-Archives-Hash: 790294f7a46496aecd0056289c4b6d08 We forbid packages from installing to /home for good reason: for most of history, users (and their home directories) were outside the purview of the package manager. But with GLEP81, that's changed: the package manager is now in charge of creating each system user's home directory and of giving it the correct permissions and ownership. Is the policy against installing to /home still consistent? For example: the mail-filter/amavisd-new daemon needs a user, typically called "amavis". The daemon also needs a working directory that it can write to. The obvious choice for a working directory is /var/lib/amavis, but there's a catch: spamassassin, razor, pyzor, et cetera (which are all used by amavis) store their configuration in the current user's home directory, and not in some daemon-specific location. So "amavis" needs a home directory, because that's where much of the configuration for amavisd goes. Where do we put amavis's home directory? 1 /var/lib/amavis is a bad idea, because it conflicts with the working directory (we don't want the two packages to get out of sync, nor do we want to keep them in-sync manually). 2 /var/lib/amavis/home was my next choice, because logically it puts the amavisd configuration in a subdirectory of the place where all of the other amavis stuff goes, and because it doesn't have the same issue that (1) does. But there's a problem: if we create /var/lib/amavis/home before amavisd-new is installed (as happens when you emerge amavisd-new), then /var/lib/amavis winds up root:root and the installation of amavisd-new doesn't change that. So now amavisd-new doesn't work, because it can't write to its working directory. This is a combination of an implementation detail and the fact that the PMS doesn't cover directories; but ultimately, it just doesn't work reliably. 3 /home/amavis also seems fine to me, except for the fact that it's a QA violation to install there. Note that we could always set system users' home directories to /home/whatever. It has only become a QA violation with GLEP81 because the eclass calls keepdir on the user's home directory. Should option (3) be viable, or do I go back to the drawing board?