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 B6E68138350 for ; Sun, 19 Jan 2020 02:50:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7FC59E0952; Sun, 19 Jan 2020 02:50:24 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 F2F5AE0946 for ; Sun, 19 Jan 2020 02:50:23 +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 861C634E275 for ; Sun, 19 Jan 2020 02:50:09 +0000 (UTC) Subject: Re: [gentoo-dev] GLEP81 and /home To: gentoo-dev@lists.gentoo.org References: <825bd707-faa2-f956-edbb-a11a8d82296b@gentoo.org> From: Michael Orlitzky Message-ID: Date: Sat, 18 Jan 2020 21:50:02 -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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: 512c26ef-e752-4365-8d3f-ee3763d969f4 X-Archives-Hash: 96ef786ac5cd6d62556de2d0b1f4da6a On 1/18/20 7:21 PM, Rich Freeman wrote: > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky wrote: >> >> But now users have to follow one more step (create /home/amavis) when >> setting up amavisd-new. Is the QA check really assuring a quality user >> experience here? >> > > Lots of daemons need a home directory for their users, and usually > they manage to get by in /var/lib. It really seems like a bad > practice to start having packages creating stuff in /home. Certainly > I don't want random daemons sticking stuff in /home, which I manage > Let's restart: * The daemon DOES NOT need a home directory for its user. * I DO NOT want to install anything to anyone's home directory. * With respect to user.eclass, I'm proposing that /home be treated EXACTLY THE SAME as it always has been. All I want to do is *set* a user's home directory to /home/foo. Some people want to configure amavis to launch a program like pyzor, which uses per-user configuration files. If you want to do that, you first log in as amavis, and run some command like $ pyzor discover which then finds some servers and creates configuration files for you in $HOME/.pyzor. This is user configuration, not daemon configuration. It doesn't belong in the daemon's working directory. In particular, you should not be dicking around in the daemon's working directory when you run "su amavis..." because what you're doing is irrelevant to the daemon. Spamassassin itself is a better example than amavis. We already set the spamd user's home directory to /home/spamd with user.eclass. We don't install anything there, and this works fine. If a human logs into that account and generates some configuration in ~/.spamassassin, then it's within the spirit of the FHS to have that data stored in /home. Now, with GLEP 81, we get a QA warning for that, because the eclass installs a keepdir file there. I would like things to remain exactly as they are, with no QA warning. Otherwise, we have to tell users to move /home/spamd to /var/lib/spamd-home or something stupid like that. I can think of no good reason to do so. > It seems like the straightforward solution is to stick everything in > /var/lib/amavis, and fix things so that everything has the right > permissions regardless of install order. Please stop telling people to do this. Calling chown on the live filesystem is rarely safe, and I already fixed one root exploit (bug 630836) in the amavisd-new ebuild from the last guy who tried to adjust wrong permissions after the fact. > Another option is to have /var/lib/amavis/home and /var/lib/amavis/work. This is better-looking than /var/lib/amavis-home, but it's still violating the spirit of the FHS to avoid triggering a warning on a dummy file.