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 9BB311396D0 for ; Wed, 30 Aug 2017 14:45:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7E3471FC0B9; Wed, 30 Aug 2017 14:45:44 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 315361FC03F for ; Wed, 30 Aug 2017 14:45:44 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id BE8D533BE95; Wed, 30 Aug 2017 14:45:41 +0000 (UTC) Message-ID: <1504104338.10801.5.camel@gentoo.org> Subject: Re: [gentoo-dev] Of death and prerm From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Wed, 30 Aug 2017 16:45:38 +0200 In-Reply-To: References: <09043e39-bcec-f73b-683e-17de59b8e5d5@gentoo.org> <1504085131.22591.6.camel@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 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 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: 00b35276-f6a8-4a0f-ad47-c4fa97fb8aeb X-Archives-Hash: 9f5ec64afe18fccbc3f7608643b96e06 W dniu śro, 30.08.2017 o godzinie 09∶15 -0400, użytkownik Michael Orlitzky napisał: > On 08/30/2017 05:25 AM, Michał Górny wrote: > > > > This package does not belong in Gentoo. We do packaging, not some ugly > > malware that prevents users from uninstalling itself. Every package must > > be uninstallable. Even if it destroys my system, developers have no > > right to prevent valid uninstall action from proceeding. > > > > So you're saying I should have it "sleep 2983702947523704" in prerm? > > =) > > I've been working on the user packages GLEP that I started and then > forgot about sometime at the beginning of the year. I'm trying to finish > up the reference implementation. > > When it comes to removing users, everyone's suggestions were along the > same lines: > > 1a. If you try to uninstall a user package, it should die(), because > calling userdel can be a security risk if the user still owns > files. > > 1b. Same as 1a, with an I_KNOW_WHAT_I_AM_DOING override. > > 2. We can scan the file system to see if the user owns anything, and > if he doesn't, call userdel. If he does, warn the user, and die(). > > 3. During upgrades, the existing user will be left in place. But If a > user package tries to switch it's UID in a new version, check to > make sure that the old UID doesn't own any files, maybe die(), etc. > > > But all of them involve being able to die() out of a removal action. > It's not refusing to uninstall the system user -- that's already the > status quo -- it's just refusing to remove the /package/ given that we > can't actually remove the system user. Trying to keep the system and the > PM in agreement (with an override). > > Anyway, I was trying to implement (1b), so that's how I found myself > asking this question. Since I'm providing an I_KNOW_WHAT_IM_DOING > override, you still have the ability to shoot yourself in the foot, but > for all of this to work I'd still need a way to stop an uninstallation. For a start, I should point out that -- unless I'm mistaken -- there is no guarantee that Portage will remove packages dependency-wise. That is, your 'user package' may actually be removed before packages that requested the user being created, and which installed files owned by that user. That put aside, I think the 'usual Gentoo way' of solving the problem you're hitting is to actually print an ewarn that the 'user has not been removed because...' with explicit instructions how to remove it after fixing the cause. -- Best regards, Michał Górny