[gentoo-dev] Of death and prerm

[gentoo-dev] Of death and prerm

[Michael Orlitzky]

What should happen if an ebuild calls "die" in pkg_prerm?

The issue arose while trying to create a package that could not be
uninstalled except as part of an upgrade. The first thing that came to
mind was to have it die in pkg_prerm.

What portage does is *appear* to crash, but then continue along as if
nothing happened.

Does the PMS cover this indirectly? (Is there a reliable way to make
package removal fail?)

Re: [gentoo-dev] Of death and prerm

[Alexis Ballier]

On Tue, 29 Aug 2017 16:38:15 -0400
Michael Orlitzky <mjo@gentoo.org> wrote:

> What should happen if an ebuild calls "die" in pkg_prerm?
> 
> The issue arose while trying to create a package that could not be
> uninstalled except as part of an upgrade. The first thing that came to
> mind was to have it die in pkg_prerm.
> 
> What portage does is *appear* to crash, but then continue along as if
> nothing happened.
> 
> Does the PMS cover this indirectly? (Is there a reliable way to make
> package removal fail?)

Is there any point in dying in any phase after (or during)
pkg_postinst ?
files are already live by then; what would this achieve ?

Re: [gentoo-dev] Of death and prerm

[Michał Górny]

W dniu wto, 29.08.2017 o godzinie 16∶38 -0400, użytkownik Michael
Orlitzky napisał:
> What should happen if an ebuild calls "die" in pkg_prerm?

Horrible things, I suppose. If something started uninstalling,
and failed during uninstall the system integrity is compromised
and user needs to perform manual recovery.

> The issue arose while trying to create a package that could not be
> uninstalled except as part of an upgrade. The first thing that came to
> mind was to have it die in pkg_prerm.

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.

> What portage does is *appear* to crash, but then continue along as if
> nothing happened.

That's probably because it wants to prevent the user from being unable
to uninstall the package, e.g. if prerm partially succeeded which means
every successive invocation would fail due to some prerm actions being
done already.

> Does the PMS cover this indirectly? (Is there a reliable way to make
> package removal fail?)

No. PMS never covered shooting yourself in the foot, it's not meant to
be fool-proof and we don't have the resources to cover every possible
bad idea Gentoo developers might come up with. Or the ability to predict
their insanity.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Of death and prerm

[Michael Orlitzky]

On 08/30/2017 04:04 AM, Alexis Ballier wrote:
> 
> Is there any point in dying in any phase after (or during)
> pkg_postinst ?
> files are already live by then; what would this achieve ?
> 

I was hoping that die() called in pkg_prerm would have a similar effect
as pressing Ctrl-C when portage is doing it's countdown thing before you
"emerge -C" package. Basically, to stop what it's doing, and to leave
the package installed. If the uninstall was part of an upgrade, the
corresponding installation (of the new version) would also fail.

Re: [gentoo-dev] Of death and prerm

[Michael Orlitzky]

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.

Re: [gentoo-dev] Of death and prerm

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

>>>>> On Wed, 30 Aug 2017, Michael Orlitzky wrote:

> 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.

This rather sounds like a case for package manager support with
some property like RESTRICT="uninstall".

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Of death and prerm

[Michael Orlitzky]

On 08/30/2017 09:26 AM, Ulrich Mueller wrote:
> 
>>   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.
> 
> This rather sounds like a case for package manager support with
> some property like RESTRICT="uninstall".
> 

Would it still be possible to override with I_KNOW_WHAT_I_AM_DOING=yes then?

Re: [gentoo-dev] Of death and prerm

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

>>>>> On Wed, 30 Aug 2017, Michael Orlitzky wrote:

>> This rather sounds like a case for package manager support with
>> some property like RESTRICT="uninstall".

> Would it still be possible to override with
> I_KNOW_WHAT_I_AM_DOING=yes then?

No. If this was to be implemented in Portage, I think the canonical
way to override it would be via some token like "force-uninstall"
in FEATURES (which can be specified on the command line too).

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Of death and prerm

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 809 bytes --]

On 30/08/17 09:40 AM, Ulrich Mueller wrote:
>>>>>> On Wed, 30 Aug 2017, Michael Orlitzky wrote:
> 
>>> This rather sounds like a case for package manager support with
>>> some property like RESTRICT="uninstall".
> 
>> Would it still be possible to override with
>> I_KNOW_WHAT_I_AM_DOING=yes then?
> 
> No. If this was to be implemented in Portage, I think the canonical
> way to override it would be via some token like "force-uninstall"
> in FEATURES (which can be specified on the command line too).
> 
> Ulrich
> 

For adding this to FEATURES and RESTRICT, are we moving into PMS
modification territory?  And if so, is this something we want to do
just for this?

(it might well be if all of this is for a proposal to extend future
EAPI anyways, I haven't been paying attention)



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 248 bytes --]

Re: [gentoo-dev] Of death and prerm

[Michael Orlitzky]

On 08/30/2017 09:46 AM, Ian Stakenvicius wrote:
> 
> For adding this to FEATURES and RESTRICT, are we moving into PMS
> modification territory?  And if so, is this something we want to do
> just for this?
> 

The new RESTRICT value would need a PMS update, but the "just for this"
part is where it gets good. The only reason I need it is for a reference
implementation of the idea that needs it, to determine if the idea is
any good or not.

It would be a lot of trouble to go through just to find out that my
proposal is junk.

Re: [gentoo-dev] Of death and prerm

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 1027 bytes --]

On 30/08/17 10:04 AM, Michael Orlitzky wrote:
> On 08/30/2017 09:46 AM, Ian Stakenvicius wrote:
>>
>> For adding this to FEATURES and RESTRICT, are we moving into PMS
>> modification territory?  And if so, is this something we want to do
>> just for this?
>>
> 
> The new RESTRICT value would need a PMS update, but the "just for this"
> part is where it gets good. The only reason I need it is for a reference
> implementation of the idea that needs it, to determine if the idea is
> any good or not.
> 
> It would be a lot of trouble to go through just to find out that my
> proposal is junk.
> 

Oh, well, a patch to portage (or an unofficial EAPI for testing) just
to evaluate your proposal wouldn't be a big deal I expect, if indeed
this is the direction to go.

I wonder though, per the original idea, wouldn't it make more sense to
allow uninstallation to continue and just very verbosely
warn/log/document what the package removal didn't do, so that it can
be done later by hand as needed?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 248 bytes --]

Re: [gentoo-dev] Of death and prerm

[Michael Orlitzky]

On 08/30/2017 10:10 AM, Ian Stakenvicius wrote:
> 
> I wonder though, per the original idea, wouldn't it make more sense to
> allow uninstallation to continue and just very verbosely
> warn/log/document what the package removal didn't do, so that it can
> be done later by hand as needed?
> 

My gut feeling is "no," but who knows. Would you want --depclean to
delete a user who owns files on your system without some prompt? The
safe move is to refuse to do it unless the user explicitly says "I've
done whatever is needed" via a variable or FEATURES or whatever.

From the GLEP-design standpoint, I like refusal because that's exactly
what we do now: leave all of the users there forever. When I'm trying to
convince you that the GLEP is an improvement, that's one less change I
have to justify.

Re: [gentoo-dev] Of death and prerm

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

>>>>> On Wed, 30 Aug 2017, Ian Stakenvicius wrote:

> For adding this to FEATURES and RESTRICT, are we moving into PMS
> modification territory?

Not necessarily. Or rather, we could proceed without modifying it,
because "Package managers may recognise other tokens" [1].

FEATURES is Portage only.

Ulrich

[1] https://projects.gentoo.org/pms/6/pms.html#x1-920008.2.8

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Of death and prerm

[Michał Górny]

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

Re: [gentoo-dev] Of death and prerm

[Michael Orlitzky]

On 08/30/2017 10:24 AM, Michael Orlitzky wrote:
> On 08/30/2017 10:10 AM, Ian Stakenvicius wrote:
>>
>> I wonder though, per the original idea, wouldn't it make more sense to
>> allow uninstallation to continue and just very verbosely
>> warn/log/document what the package removal didn't do, so that it can
>> be done later by hand as needed?
>>
> 
> My gut feeling is "no," but who knows. Would you want --depclean to
> delete a user who owns files on your system without some prompt?

Ugh, nevermind -- my response is nonsense now that I re-read what you
asked. I think I've been waking up too early.

The downside to removing the package but not actually removing the user
is that you no longer have an accurate record of which users portage
installed for you. That list of no-longer-necessary-but-still-present
users is like a TODO list for people to keep their systems clean.
Keeping a bunch of unused system accounts -- some with shell access --
is its own risk.

Right now my /etc/passwd contains 29 lines, and I don't know which ones
I can delete. I think it's a nice feature if we can remedy that; running
--depclean would tell me which users are no longer needed, and after
I've cleaned up their files, I could userdel them and force portage to
uninstall the associated packages.