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 3963F138350 for ; Sun, 19 Jan 2020 19:19:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 33432E0929; Sun, 19 Jan 2020 19:19:21 +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 DED90E08F0 for ; Sun, 19 Jan 2020 19:19:20 +0000 (UTC) Received: by mail-io1-xd43.google.com with SMTP id k24so31374225ioc.4 for ; Sun, 19 Jan 2020 11:19:20 -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=J8GFBFfAAymLS1Q3FZ1ilSrAOlERLcnRzDU99RHW/Og=; b=RuYKMKPAOeFPMMTjia5+kjxr4EYAzNqV6pRDHfqWlye2qUwHWexc1NWpWl7n8WF8Rq Rjc+iVeQCp1WtE9pMn5K88TsJmXF27nFKbH1aBtZOhBkLlbQMf3lu3hcdKKM+bjZvVc/ Lzcl670yNShWqaa7mmOarfWucJdxksn7FU1RfAClCTGWTlyr6eZOqBSD4RukV20dZOQk qTvvgX+MxVGW1I7fqt9nyFfwVZbO60qgHUNQJrtJ645rSW+zHjqlnxp+AQ2CSTzWiaHG AgEEdS5pEL2pU+wh6y7SYqU1toIlFAEtikuwrcjuiJbPFnKcmF/aKCZTQCcpWNZkAenI zGaA== 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=J8GFBFfAAymLS1Q3FZ1ilSrAOlERLcnRzDU99RHW/Og=; b=s3Aw5+qQQPfPgma0KWGMXR6Ft2mqeApQ0cUCQP0Fq8HYn9sfAofWwitv+ZqGv6lZmo OElFEBxnDiNstRKzmeGPxHir4aZKuaosjKrycfLGHJqQtvBuA5UGjih8bJStBLrKvZcT dKclqHweRVvhBnXBcG5T03IVP1jKKjAQTo3CkmDTBdD1pzDq7bAlIQbP3oS+znwdX76H +t0xm3xLX5xhRe5H7SHbbNVni0k2Dh+ZRqIIlp3Zs2EhdIm+MaDlhOZFe9umNDG+gvUv DNOsBlauz58TaBJy5OWdE77HKsNd3EUXv8Hjd9ZTS76kEsoj2JYF4CNh1TpVGo65XB2f TMow== X-Gm-Message-State: APjAAAXb3nSJQHCcOpqqBAHD+Z23l8pC5Z0ZQJdJwV/9xvgMjHn97SeC bPlMkuCQpmvVHCTKP7Ya6Mm9291A2GSkftC6+b7Du/UwBE4= X-Google-Smtp-Source: APXvYqyn32f/gKMQIQMeSe95NsxLb8cRsNwiQAa+1bLEf3deh0fobIhapaIY1FHSWhA/G2J/n+D1piPbseoG+WWVMs0= X-Received: by 2002:a6b:6a02:: with SMTP id x2mr37588362iog.20.1579461559654; Sun, 19 Jan 2020 11:19:19 -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: <825bd707-faa2-f956-edbb-a11a8d82296b@gentoo.org> In-Reply-To: From: Alec Warner Date: Sun, 19 Jan 2020 11:19:08 -0800 Message-ID: Subject: Re: [gentoo-dev] GLEP81 and /home To: Gentoo Dev Content-Type: multipart/alternative; boundary="000000000000332f0c059c830de2" X-Archives-Salt: efdde824-d3ed-4376-8bb5-08838cb3e941 X-Archives-Hash: fca2274beec95ce070d8120c98a62d5b --000000000000332f0c059c830de2 Content-Type: text/plain; charset="UTF-8" On Sat, Jan 18, 2020 at 6:50 PM Michael Orlitzky wrote: > 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. > Why wouldn't you set the homedirectory to /dev/null then? -A > > 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. > > --000000000000332f0c059c830de2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jan 18, 2020 at 6:50 PM Micha= el Orlitzky <mjo@gentoo.org> wr= ote:
On 1/18/20 = 7:21 PM, Rich Freeman wrote:
> On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky <mjo@gentoo.org> wrote:
>>
>> But now users have to follow one more step (create /home/amavis) w= hen
>> 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.=C2=A0 It really seems like a bad > practice to start having packages creating stuff in /home.=C2=A0 Certa= inly
> I don't want random daemons sticking stuff in /home, which I manag= e
>

Let's restart:

=C2=A0 * The daemon DOES NOT need a home directory for its user.
=C2=A0 * I DO NOT want to install anything to anyone's home directory.<= br> =C2=A0 * With respect to user.eclass, I'm proposing that /home be treat= ed
=C2=A0 =C2=A0 EXACTLY THE SAME as it always has been.

All I want to do is *set* a user's home directory to /home/foo.

Why wouldn't you set the homedirectory to = /dev/null then?

-A
=C2=A0

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

=C2=A0 $ 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<= br> amavis..." because what you're doing is irrelevant to the daemon.<= br>
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<= br> 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/wor= k.

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.

--000000000000332f0c059c830de2--