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 DC4F0138350 for ; Mon, 20 Jan 2020 02:52:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CD019E09C0; Mon, 20 Jan 2020 02:52:38 +0000 (UTC) Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) (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 88EC6E09A6 for ; Mon, 20 Jan 2020 02:52:38 +0000 (UTC) Received: by mail-pj1-f50.google.com with SMTP id u63so5726306pjb.0 for ; Sun, 19 Jan 2020 18:52:38 -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=GUkz5hJWRN12vds3hKQ9akPG1I59rBjhtthgEr1YZPI=; b=eXSnikOwjJNL1UpmkOY/eJooQO98gMaAMLSBxdR8qLSujGKN8I9Wv0/xmUgKklYW5z 2jCw2oKYULWvzZH7vwPEWdKFudS6KIWDWeRAGYyWZnWRr32ASOKHan5HAKE2vf/n74d8 nBaLfVVtxZYXAmznnAII1066QJ98qigBiaV7ogMWvEVpBp6rk//I9IKZRBLKTCekyR9M mhzAXetbNe4kd8XAGvqqfdof4YAL4DqJbSP9NP8wQLcTd+d0vSNE3/yRGHGcTHgzCRcW 2AcrlnRrTD8ehpm9530T4Ps2RPvlM9WQrwwtCv+9mG+wu1ldPiXdBkFz2yj8XvYdwHY/ c5Rw== X-Gm-Message-State: APjAAAU5cN9MPCaS3/ud5p1XjlBhk/LCcLrYf5tciZgXkdSF5fuPRtxs IuARBt5XzNmog1N2Ue/dRUmJjNUxkWgWRdUuK5cGbEuISS0= X-Google-Smtp-Source: APXvYqzspBgPpnkFOnUvJYGgOf5Rirdf8sJXEYNMAoUeRpviGXRA59Pm4S4GmngSpwvckXofUNOrh7BOnaBuDaBlE9M= X-Received: by 2002:a17:902:a9c7:: with SMTP id b7mr12473816plr.255.1579488756972; Sun, 19 Jan 2020 18:52:36 -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> <4c60e5c5-92ce-09f0-09c5-a7338bb9cfb3@gentoo.org> <21efee36-dcc8-bb14-9fb9-0d6b2abf8c8d@gentoo.org> <5e98c62e-3501-9322-7129-a9d6105a6126@gentoo.org> <6d0bbd7c-27e2-4973-2f11-074c1fa48b6b@gentoo.org> In-Reply-To: <6d0bbd7c-27e2-4973-2f11-074c1fa48b6b@gentoo.org> From: Rich Freeman Date: Sun, 19 Jan 2020 21:52:27 -0500 Message-ID: Subject: Re: [gentoo-dev] GLEP81 and /home To: gentoo-dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 0cde27ac-b5ff-4b29-95d4-31f5a3f8a933 X-Archives-Hash: 46e6b1c329ace5643d4c1fb326e5e86f On Sun, Jan 19, 2020 at 8:51 PM Michael Orlitzky wrote: > > On 1/19/20 8:20 PM, Rich Freeman wrote: > > It would be far simpler for the sysadmin to simply ensure that no > > unsynced user owns a file or appears in an ACL. That would be pretty > > trivial to achieve. Whatever is hosting /home could be designed to > > block such changes, or you could just scan for these ownership issues > > periodically and treat those responsible for them appropriately. > > Fantasy scenarios again. I'm not going to debunk a system that you just > thought up and that has never existed. Why don't you find one person who > actually does this, and see if it bothers him if we create a home > directory under /home where it belongs? Uh, I'm pretty confident that nothing in my /home is owned by a UID under 1000, or has an ACL referencing such a UID. I just checked with myself and I don't want you creating directories in /home. This really seems like it has the potential to create a mess for anybody using LUKS-encrypted home directories, stuff mounted from CIFS, and so on. While I personally don't do either it seems fairly mainstream, and I could eventually see myself using it more once better supported on Gentoo (such as when systemd-homed is more mainstream). > > On the topic of treating those responsible appropriately, somehow I > > could see this scenario turning into a quiz question. > > > > I mean, would it kill you to just talk to QA first? > > I've already got responses from two QA members. This thread is pretty > hard to miss. Well, then why go posting stuff like "guess we'll be triggering a warning after all?" > I'm working on a patch for the install-qa-check.d check > and I'm sure I'll get more when I post it. Are you just allowing it to not create the directory, or are we considering patching it to allow creating stuff under /home? It would seem that the policy would also need updating in that case, but probably not the former. -- Rich