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 F37B8138334 for ; Fri, 31 May 2019 07:48:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 92CD2E088D; Fri, 31 May 2019 07:48:33 +0000 (UTC) Received: from othala.iewc.co.za (othala.iewc.co.za [IPv6:2c0f:f720:0:1:21e:67ff:fe14:6ae5]) (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 1FFC3E0887 for ; Fri, 31 May 2019 07:48:32 +0000 (UTC) Received: from [165.16.203.61] (helo=tauri) by othala.iewc.co.za with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hWcH5-00042u-Gj for gentoo-dev@lists.gentoo.org; Fri, 31 May 2019 09:48:27 +0200 Received: from plastiekpoot.dhcp.uls.co.za ([192.168.42.155]) by tauri with esmtp (Exim 4.91) (envelope-from ) id 1hWcH4-00075K-M5 for gentoo-dev@lists.gentoo.org; Fri, 31 May 2019 09:48:26 +0200 Subject: Re: [gentoo-dev] [pre-GLEP] User and group management via dedicated packages To: gentoo-dev@lists.gentoo.org References: From: Jaco Kroon Organization: Ultimate Linux Solutions (Pty) Ltd Message-ID: <56dc2b2e-d7ff-68d1-bbbe-85c1491f3e5e@uls.co.za> Date: Fri, 31 May 2019 09:48:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-report: Relay access (othala.iewc.co.za). X-Archives-Salt: 41ee538f-c29f-4534-b100-0648dc48b9f7 X-Archives-Hash: ccc92d8ab43d1c1e0151451ac638e1d6 Hi, On 2019/05/29 18:01, Michael Orlitzky wrote: > On 5/29/19 5:50 AM, Jaco Kroon wrote: >>> This GLEP follows the best practice of leaving obsolete user/groups >>> accounts intact. This guarantees that no files with stale ownership are >>> left (e.g. on unmounted filesystems) and that the same UID/GID is not >>> reused for another user/group. >> The type of checks for both this and certain updates contemplated above >> are similar.  And expensive (resources) as you rightly say. I would >> provide the tools to perform these checks but in the ebuild I'd rather >> the checks be done asap (pkg_pretend?).  If we can fail there and >> stating what the admin should do to rectify the issue that would be the >> best solution in my personal opinion.  Ie, from the package manager I'd >> state how, but not actually action these changes. >> > My original goal here was to have "emerge -C " actually uninstall > the user. That turns out to be highly unwise, because you need to audit > the system for things owned and used by said user, and to clean them all > up beforehand. That can take forever, and can't be automated. > > Plan (b) was to do exactly as you asked: have the uninstall process bail > out, and tell you what to do. That's... also technically infeasible, > because we don't have a way to make an ebuild bail out of an uninstall. > This could change in the future with an EAPI/PMS update, but simply > isn't an option right now. I think you misunderstood.  My writing was poor on re-read. My suggestion is to merely lock the user.  And make sure that the admin knows this.  Even locking may need to be configurable but by default I would lock. Further, the tools should be provided outside of the ebuild (baselayout perhaps) in order to enable the checks to be completed (ie, confirm no files has the user as owner), and then report to the sysadmin how to use these tools. On merge:  Perform the checks before any building starts (pkg_pretend/pkg_setup, as per libreoffice example I just looked at).  Need to recheck again obviously just prior to actually making the changes.  Bail early in other words during install. On unmerge:  Lock user.  Advise sysadmin on how to actually remove the user (possibly put it in a database somewhere and check somewhere in portage that these users are "linkgering", similar to retained libs that gets held because of binaries actually still using it, but never automatically removed, just checked if the sysadmin has).  Can't (should not) fail. I hope that clarifies. Kind Regards, Jaco