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 54B7B138350 for ; Sun, 19 Jan 2020 17:42:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2FE63E096B; Sun, 19 Jan 2020 17:42:47 +0000 (UTC) Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) (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 E74E7E086B for ; Sun, 19 Jan 2020 17:42:46 +0000 (UTC) Received: by mail-pg1-f195.google.com with SMTP id b9so14273469pgk.12 for ; Sun, 19 Jan 2020 09:42:46 -0800 (PST) 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=haX2lHfkHpliw5M975F2WfyIOIrluWLJiLLvd9bgZ74=; b=iZx6AQfMA9RjG5qK3gsZK6W/lS/DWBo/glr7cO5Us4avSnimUb5PWHc5BKhU5KedGf MdKwGT9++rHYQ4HsHqpY1BPB4YCVPAtyra3NcSaKNB6Xgrt5B+d+Veh9ORLk/0PlzekC 4vJJ+oPij7GUMC0D+JTIY7kLpACBiajkh9EjVGuTmRPiSr/7c/ko/UqM+wn5e9iul/Mx VOkkOwqiPvTnrFLZqyMSu1UEOseyVYXreNkdIkPOr/8/mb68Uj5pPAJSrIMHOs3bI9Bo iF+Xh57dW/HDwvIUJ9Fbb/jtDdiSAJvdmgZPUj8eSe4W6WG4Y92a0Wiht92wQPQZhDS5 1wbA== X-Gm-Message-State: APjAAAUVP12n1v/m6TLDrc+H0Se5O59zhygcoA3GDCLnOZiSuSv4ILEl HIU1O/OdrDmRC2kJ8TwQ2CrWF6DxYk/69LyG2ym1k3nQc0Y= X-Google-Smtp-Source: APXvYqwIYGVUU+LhtfPcfTZQCDyfDRPX0/+jGJwNxg7Gti8NzWIgHK3j8Nz7LXj/dkTv6lkag+iFIsmesoPplv2LV9U= X-Received: by 2002:a63:8041:: with SMTP id j62mr56208110pgd.41.1579455765229; Sun, 19 Jan 2020 09:42:45 -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> <2313c928-6c17-394c-d437-b5ad1f76ecea@gentoo.org> In-Reply-To: <2313c928-6c17-394c-d437-b5ad1f76ecea@gentoo.org> From: Rich Freeman Date: Sun, 19 Jan 2020 12:42:34 -0500 Message-ID: Subject: Re: [gentoo-dev] GLEP81 and /home To: gentoo-dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: c9fd9c88-c23c-4537-8ad8-867860b7b164 X-Archives-Hash: dda5f031f7c45be9fccb684906abc2f8 On Sun, Jan 19, 2020 at 10:49 AM Michael Orlitzky wrote: > > On 1/19/20 6:29 AM, Rich Freeman wrote: > > > > Daemons are local users. There is no guarantee that /home is a local > > filesystem. Heck, there is no guarantee that /home is even mounted > > when portage is running. Portage shouldn't be touching /home at all. > > With stuff like automounted or encrypted home directories and > > systemd-homed and so on it seems like it is even more important to > > avoid sticking stuff in /home (and this is hardly something started by > > systemd - stuff in /home that is non-static has been a thing for some > > time - certainly it was happening in the 90s on some IRIX workstations > > I used). > > If you're sharing /home, you're also sharing users. At that point, the > daemon user is no longer local. Typically you wouldn't share service accounts across multiple hosts. I'd think that something like amavisd is going to go on a mail server. You're not going to be logging into that account to do typical desktop-oriented functions. If you had three mail servers, you probably would want to share /home/mjo across all of them, but you probably wouldn't want to share your amavisd config across them. That is why the config goes in /etc. I don't see how stuff it launches would be any different. This is why /root is typically outside of /home as well. > I like your /var/lib/amavis/{home,work} suggestion second-best, but the > most appropriate place for the home directory of an account that will be > used interactively by a human (even if it's also used to start a daemon) > is under /home. For example I do want to back up that home directory, > but I don't want to back up the working directory. Honestly, since you're only using it for what amounts to configuration it almost makes sense to put it in /etc, and back it up for that reason. You don't really want to be using it interactively as a human per-se any more than you interactively log in as root or any other service account. There are rare occassions where I'll launch a shell as apache or postfix or whatever, but that doesn't mean that you want it to have a home in /home. > > Portage should provide a safe mechanism to fix permissions. Or we > > should just avoid nesting user home directories inside directories > > that will be written to by that user. > > > > If this is the same hard-linking concern as with tmpfiles.d then > > somebody really just needs to fix POSIX. :) But as a workaround just > > avoiding nesting seems like the simpler solution... > > Essentially yes, but hard links aren't the only problem. It's unsafe to > do anything as root in a user-controlled directory. POSIX can't fix > that, and that means that portage will never be able to fix permissions > (or do anything else) within a user-controlled directory safely. I mean, you're still doing stuff as root. You're just not running chown. POSIX certainly could fix it, though whether it could do it in a manner that doesn't break everything in existence is another matter. For example, if POSIX just got rid of hard links many of the issues would just go away. Obviously if the problem had a simple solution it would have been implemented by now. BTW, thanks to the recent QA post I can at least point you at documentation for your issue. Per the article if you want to change it the procedure is to ask QA for an exception or change in policy, and if you don't like the answer go to Council... https://projects.gentoo.org/qa/policy-guide/filesystem.html#installation-paths -- Rich