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 5EC3C138350 for ; Sat, 18 Jan 2020 19:04:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ADE30E08F6; Sat, 18 Jan 2020 19:04:05 +0000 (UTC) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 64AE9E08D3 for ; Sat, 18 Jan 2020 19:04:04 +0000 (UTC) Received: by mail-io1-xd2b.google.com with SMTP id i11so29486676ioi.12 for ; Sat, 18 Jan 2020 11:04:04 -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=/Oaz1WxdLuhCdI2oY0DrEBaJBhQ0q/paairOeFW4njw=; b=vaReu8h2rQmzLTEB4ixwEBNIT5inzhlAIETiCXo1rVafkvWYQzh8MaQCGvRP2tg5Ua FZrCpZqOFWrek953tALWM0jzg+/dEXk3+sZFMIKnBIlA9s+1Kwl2OxK+/0Ekf1UlkkND qylYBdhvCfgYhh5mOAOD4TmhVFMcOpvW/CryL6clLDUV9mlxNoQSema2Fi3NCVew4ach m2C14+GPN6Fl3Xf31ZMmyDLD8oLyv9aVWT1iXqvOMWZ3o5yBx9oT/Y9ggUsrOsggo434 Kh2hTLL8lLNaGjXLM5qm8hlC46IjccSOgvchHlDKc7U4PqOPzJ9yfIcaODwz6HD41o9m kz/w== 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=/Oaz1WxdLuhCdI2oY0DrEBaJBhQ0q/paairOeFW4njw=; b=R2tLHkRV7Ge/vLBFJYJj+1tbbJvdsrQAMAXXV7NN4FLpzkSxPZQuBHOlnTV1YS19S8 plcY6CorFIbPKp0t+FPDQHhF5X1ssa4cyJjnF8qEDGt2dr9BVJ9iuDR9pFBiz468Xl8d 2Z3cD9NQQONrgyT7IFxYJwEJs+vQI9ULV29GRXHtoJ1Cy8QHfNUtSesCUKeTBeNlNFp4 OkbmyqdZCj9zykzQB4o2MzvaMg2nnS8N6Ym6memB/2DvETWlm1hqBoWABCQAMmRdXwiA 2w0Dbw7Hp2w7yZIn5pviazWVWU7fJuz5gyncP0L6fNxgQivIxjtfafeM6rawr6x3c9oK p3aA== X-Gm-Message-State: APjAAAUZ/xM28dfYvhVL2KsrtRIHqhwziCmNYi+10eI50el1RlJGnYeH 8WPFN61jMqd3nmYqZSCZSOo/J/xJ+t/okoo+bvAs0dD2N4A= X-Google-Smtp-Source: APXvYqxUH0oKSV1jFlDiD43I9KFI2rOeSmpP3NegXmN9gpXINMCGbwLzFnZJ9aLAeuDawNl1lt+PRBGle+Dz9wNw/Ls= X-Received: by 2002:a05:6638:10e:: with SMTP id x14mr38014879jao.4.1579374243026; Sat, 18 Jan 2020 11:04:03 -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: <825bd707-faa2-f956-edbb-a11a8d82296b@gentoo.org> From: Alec Warner Date: Sat, 18 Jan 2020 11:03:51 -0800 Message-ID: Subject: Re: [gentoo-dev] GLEP81 and /home To: Gentoo Dev Content-Type: multipart/alternative; boundary="000000000000b9453c059c6eb827" X-Archives-Salt: 63695626-6a3d-416e-852e-54055f157bab X-Archives-Hash: 645d2932992bff87d3bd8b5b566c5a3d --000000000000b9453c059c6eb827 Content-Type: text/plain; charset="UTF-8" On Sat, Jan 18, 2020 at 9:52 AM Michael Orlitzky wrote: > 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? > I tend to agree that in theory keeping the working directory and home directory the same is not ideal. However I'm not really aware of any practical problems. Haven't we basically run in this configuration for years? What kind of issues does it pose (outside of "well it sounds like not the best idea?") Agreeing with ulm here. I think the potential struggle for (3) is that conceptually /home is not always system specific. If /home is shared, you could end up with a bad time (e.g. I *don't* want /home/amavis shared across all my hosts, how would I manage multiple versions? Multiple configs?) Often all of /home is mounted and it becomes tricky to build workarounds. You could do things like "symlink /home/amavisd to some local path". At work we use /usr/local/google/home/$USER for this purpose; but it is basically a vestigial artifact from an earlier time than something we explicitly designed. Even the symlink solution is not ideal. NFS can present some exciting reliability issues and so having to touch NFS just to read the symlink (pointing locally) is probably not something I'd advise at scale; it would be simpler to change the users homedir to be elsewhere. Note that I'd expect large scale installs to do this anyway (I wouldn't rely on GLEP81 to manage users in an enterprise environment) but i'm not sure if the entire community shares that belief ;) -A --000000000000b9453c059c6eb827 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jan 18, 2020 at 9:52 AM Michael O= rlitzky <mjo@gentoo.org> wrote:=
We forbid packages from installing to /home for good reason: fo= r 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<= br> 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 i= t 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 hom= e
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?

=C2=A0 1 /var/lib/amavis is a bad idea, because it conflicts with the worki= ng
=C2=A0 =C2=A0 directory (we don't want the two packages to get out of s= ync, nor do
=C2=A0 =C2=A0 we want to keep them in-sync manually).

=C2=A0 2 /var/lib/amavis/home was my next choice, because logically it puts=
=C2=A0 =C2=A0 the amavisd configuration in a subdirectory of the place wher= e all
=C2=A0 =C2=A0 of the other amavis stuff goes, and because it doesn't ha= ve the
=C2=A0 =C2=A0 same issue that (1) does.

=C2=A0 =C2=A0 But there's a problem: if we create /var/lib/amavis/home = before
=C2=A0 =C2=A0 amavisd-new is installed (as happens when you emerge amavisd-= new),
=C2=A0 =C2=A0 then /var/lib/amavis winds up root:root and the installation = of
=C2=A0 =C2=A0 amavisd-new doesn't change that. So now amavisd-new doesn= 't work,
=C2=A0 =C2=A0 because it can't write to its working directory.

=C2=A0 =C2=A0 This is a combination of an implementation detail and the fac= t that
=C2=A0 =C2=A0 the PMS doesn't cover directories; but ultimately, it jus= t doesn't
=C2=A0 =C2=A0 work reliably.

=C2=A0 3 /home/amavis also seems fine to me, except for the fact that it= 9;s a
=C2=A0 =C2=A0 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?

I tend to agree that in theory keeping the work= ing directory and home directory the same is not ideal. However=C2=A0 I'= ;m not really aware of any practical problems. Haven't we basically run= in this configuration for years? What kind of issues does it pose (outside= of "well it sounds like not the best idea?")

Agreeing with ulm here. I think the potential struggle for (3) is tha= t conceptually /home is not always system specific. If /home is shared, you= could end up with a bad time (e.g. I *don't* want /home/amavis shared = across all my hosts, how would I manage multiple versions? Multiple configs= ?) Often all of /home is mounted and it becomes tricky to build workarounds= . You could do things like "symlink /home/amavisd to some local path&q= uot;. At work we use /usr/local/google/home/$USER for this purpose; but it = is basically a vestigial artifact from an earlier time than something we ex= plicitly designed.

Even the symlink solution is no= t ideal. NFS can present some exciting reliability issues and so having to = touch NFS just to read the symlink (pointing locally) is probably not somet= hing I'd advise at scale; it would be simpler to change the users homed= ir to be elsewhere. Note that I'd expect large scale installs to do thi= s anyway (I wouldn't rely on GLEP81 to manage users in an enterprise en= vironment) but i'm not sure if the entire community shares that belief = ;)

-A



=

=C2=A0
--000000000000b9453c059c6eb827--