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 0FB28138350 for ; Mon, 20 Jan 2020 01:20:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 68AACE0992; Mon, 20 Jan 2020 01:20:40 +0000 (UTC) Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) (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 23335E0957 for ; Mon, 20 Jan 2020 01:20:39 +0000 (UTC) Received: by mail-pg1-f172.google.com with SMTP id s64so14664015pgb.9 for ; Sun, 19 Jan 2020 17:20:39 -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=o3qJCTSChY78EtWhTasw8yF8KLtdcK42RPkPt/1vOqc=; b=qBit0A4FLlyEMoS+YTBlBmDRm3WHujDkRusFfqS1HSsC3Vc21gtv8BYEPn/XbIJ48D 4mOBfsN3vPVGDh4hnTHneahnBWe9UHUw/CpNdm+mIACdGPh3q4dssxLJRFsh2u4+D0an Lz8ADQmCQu2TnkBvbBan/l2FvFqCPITwf8O5RbiuT/FlE53v920LBCe9EbrAizGhV0TS VndFTjjJyw8VG9nvNAxIQcT7ISAW8sQluDbJDMbddVVLEhTcG8Lc5SbYLUHHfB2nr2dJ zK209fHRRUWQH+bl1czFyHcirNdeiLcrPxHCBkbZU867V5l2B/Z7OF+cZRzlymDoJnsp Il+w== X-Gm-Message-State: APjAAAUtW7xTGXVXXCz1TrxAb1yBquVmqN0rhMxM5aXzxasJO7y9sq1f TQ8OkbkT5fnkOvvUtETUdIpfaIFg4yKDtranmzy8YrCumhQ= X-Google-Smtp-Source: APXvYqzNNwAU+XiQfF3TsUVQCahXxRcW6RXhLC6Otg9JLy7yok0vcxXTzqLo3tD0z1bfN5FxBd6slFn6BUmBaAM4HYM= X-Received: by 2002:a63:d00f:: with SMTP id z15mr57250667pgf.143.1579483238266; Sun, 19 Jan 2020 17:20:38 -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> In-Reply-To: <5e98c62e-3501-9322-7129-a9d6105a6126@gentoo.org> From: Rich Freeman Date: Sun, 19 Jan 2020 20:20:28 -0500 Message-ID: Subject: Re: [gentoo-dev] GLEP81 and /home To: gentoo-dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: b2034326-b483-4b7a-af10-8c8d823a3e20 X-Archives-Hash: bfa225ceb958aacffc59118755da419a On Sun, Jan 19, 2020 at 4:00 PM Michael Orlitzky wrote: > > On 1/19/20 2:47 PM, Rich Freeman wrote: > > > > Obviously the UIDs associated with the shared /home need to be > > identical. Simplest solution is to sync anything > 1000 in > > /etc/passwd, and then not allow UIDs below 1000 in /home. A cron job > > could easily handle both, and of course regular users can't go > > creating stuff with the wrong UID anyway. > > That's not enough. You also need to sync any user/group that appears as > the owner or group of a file in /home, and every user/group that appears > in an ACL in /home, and so on. And since you have no idea what files or > access control lists will show up in /home, you'd better sync them all. That doesn't seem reasonable, considering that this could require syncing across various Distros, or even various Unix-like OSes. 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. In any case, maintaining permissions on stuff in /home is a sysadmin responsibility, not a distro responsibility. On Sun, Jan 19, 2020 at 5:09 PM Michael Orlitzky wrote: > > Just kidding, the eclass is rigged to die in src_install if you delete > the home directory, and if you wait until pkg_preinst, the warning gets > shown anyway (for a file that's not there, noice). > > Guess we'll be triggering a warning after all. 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? -- Rich