gdebi-gtk calls pkexec inappropriately

So a workaround for anyone reading this... (thanks to alkisg on freenode for working with me on this)...

sudo rm /usr/bin/gdebi-gtk
echo '#!/bin/sh' | sudo tee /usr/bin/gdebi-gtk
echo '/usr/share/gdebi/gdebi-gtk "$@"' | sudo tee -a /usr/bin/gdebi-gtk
sudo chmod +x /usr/bin/gdebi-gtk

Don't worry deleting 'gdebi-gtk' on that first line, it's only a symlink.

Basically this wrapper is needed otherwise policy kit complains and states "Refusing to render service to dead parents."

Goes back further than Ubuntu 18.04 then...

https://stackoverflow.com/questions/49214954/gdebi-refusing-to-render-service-to-dead-parents

The following workaround doesn't remove anything and allows the wrapper to survive updates:

sudo -i
printf '#!/bin/sh\n\n/usr/share/gdebi/gdebi-gtk "$@"\n' > /usr/local/bin/gdebi-gtk
chmod +x /usr/local/bin/gdebi-gtk
exit

No issue on Ubuntu MATE 19.10! This was tested with Firefox 70.0.1 and the Minecraft deb package.

Still seeing this issue on 19.10 with Firefox and 20.04 also.

Status changed to 'Confirmed' because the bug affects multiple users.

Still happens on Focal final. Do not have any clues how to debug this.

The problem is not in firefox or mate, it's in gdebi-gtk, and specifically in GDebiGtk.py, line 619:

os.execv(pkexec_cmd, pkexec_args+gdebi_args)

This replaces the current process with a pkexec call. This is not a valid usage of pkexec, as pkexec requires the parent process to not be init (ppid!=1).

To reproduce the issue without firefox, one can just run `setsid gdebi-gtk package.deb`.

In a similar bug report for update-manager (LP: #1020115), this flag was used instead of os.execv:

flags = GObject.SPAWN_DO_NOT_REAP_CHILD
https://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main/view/head:/UpdateManager/backend/InstallBackendSynaptic.py#L63

Is gdebi still maintained by Ubuntu developers, or should we report this in Debian?
Can we propose a patch similar to the update manager, or even just use a simple shell wrapper?

Thanks for the workarounds! Fantastic that progress is picking up, it seemed doubtful this would ever be resolved. ⏳😅

Still happens on Bionic. Need official fix.

Can somebody please re-check and confirm on focal? On UM focal I'm not seeing this issue but do so on hirsute and impish.

When we click on a .deb file firefox asks 'What should Firefox do with this file?, with `open with` and `save` being two options. I tried the following one by one.
  a) Chose open with. Install with gdebi was OK.
  b) Chose save. But opened downloaded file from within firefox (from download icon on navigation bar). OK.
  c) Chose save but then opened downloaded file from Caja. OK.

On hirsute and impish only c) works. a) and b) fail.

Gdebi version on focal: 0.9.5.7+nmu3

I'm seeing the same buggy behavior on freshly installed Ubuntu MATE 20.04.2 LTS running inside VirtualBox.

21.04 is still affected.

21.10 is confirmed as affected.

I recently noticed that this is no longer occurring on Ubuntu MATE 20.04.3. I am uncertain when it was fixed.

@Patrick Fasano (kc9jud)

I've just made a new blank VM, downloaded a fresh copy of the Ubuntu MATE 20.04.3 amd64 ISO... and installed it (the only choices I made of note were.. picking a Minimal install with 3rd party firmware/codecs/etc..)

I can not confirm your findings.

I tried going to these sites to download their 64-bit .deb packages (follow the most obvious links to download on each site)...
- nomachine.com
- teamviewer.com
- skype.com

And found that whether you...
a) allow Firefox to save to disk and afterwards open the .deb from within Firefox (either from the Downloads button on the toolbar, or within the Library window of Firefox)... or...
b) ask Firefox to 'Open with' the 'GDebi Package Installer (default)' upon it finishing the download...

You get the same issue where GDebi opens but the 'Install Package' button makes GDebi instantly close.

However (just as before), if you go to your Downloads folder in an actual file manager (outside of a web browser like Firefox or Chrome) and open the .deb... then the 'Install Package' button functions normally.

Nothing has really changed with this bug at all... I'm pretty sure I first noticed this way back in 14.04 (so this bug is now over 6 years old in reality) and it's one of the worse experiences a first time user of Linux could have.

Especially when you consider most have come from a world where a .exe or a .dmg (when downloaded)... "Just works".

Bug still exists in 22.04.

I have no idea what I'm doing here in terms of submission processes, but I attempted to submit a patch for this issue:

https://code.launchpad.net/~macg3/ubuntu/+source/gdebi/+git/gdebi/+merge/414211

I suspect I may have done something wrong in the submission process because "git-ubuntu import" is listed as the code reviewer. It was really confusing because there was also a bzr project for this package that is outdated, and it appears it has been moved to Git. Anyway, this patch fixes the issue by adding a separate python script that acts as the parent process for pkexec. Special thanks to Alkis Georgopoulos for all of the info provided above.

I've linked the MP and subscribed ~ubuntu-sponsors.

Please address Julian's feedback in https://code.launchpad.net/~macg3/ubuntu/+source/gdebi/+git/gdebi/+merge/414211 and then subscribe ~ubuntu-sponsors again.

It appears that this bug no longer affects newer versions of Ubuntu. It's unclear to me exactly how this change happened, but in 23.04, running "setsid pkexec echo hello" for example no longer prints the "Refusing to render service to dead parents." message, and instead works correctly. The original reproduction steps with Firefox/Chrome also don't cause the problem anymore.

The difference seems to be that when you run pkexec like that, it now gets parented to "systemd --user" in modern Ubuntu versions instead of init, so pkexec is no longer unhappy about it.

I can still spend some time tweaking the merge request as per Julian's feedback if there is any chance that this would result in new builds of gdebi for the older affected versions like 20.04 and 22.04.

I take back what I said in my previous comment. This does still affect 23.04, at least with Ubuntu MATE and Chrome. It all depends on how the processes are parented, which changes based on how you launch Chrome.

If I launch Chrome from the MATE menu, it gets parented to "systemd --user" and this problem doesn't occur. If I launch Chrome by clicking its icon in mate-panel, it gets parented to mate-panel instead, which follows a parenting chain of mate-session -> lightdm -> init. This difference also affects how gdebi ends up being parented when Chrome launches it from its downloads. gdebi ends up parented to init if I try to open a Chrome download from Chrome after I've launched Chrome from the panel, and this problem occurs.

The same can be said about the "setsid gdebi-gtk package.deb" command. If I start MATE Terminal from the MATE menu and run that command, it works fine. If I start MATE Terminal from mate-panel and run the same command, it immediately exits and I get the "Refusing to render service to dead parents." message instead.

I suspect this difference explains why some people haven't been able to reproduce this problem but others have. I will point out that Firefox, regardless of how it's launched, seems to not be affected anymore. gdebi always ends up parented by systemd when Firefox launches it.

Clearly there is still value in fixing this in gdebi. I'll look into addressing Julian's feedback and resubmitting the fix.

Feedback on the patch has been addressed and it has been resubmitted.

> I will point out that Firefox, regardless of how it's launched, seems to not be affected anymore.

If you're testing firefox.snap, that might be the cause, i.e. maybe snap does the parenting.
While e.g. firefox.deb from the mozillateam PPA (or firefox in Debian) could still have the issue.

Thanks for working on this!

Hi Alkis,

You are absolutely correct. I just removed the firefox snap and installed it through the mozillateam PPA instead, and indeed, gdebi ends up parented by init when launched through Firefox's downloads, just like what I saw with Chrome, and the same issue is reproducible (my patch fixes it). So snap has been hiding the problem. Thanks for pointing that out!

This looks good to me, but the process to land this seems a bit complicated because gdebi seems to be abandoned at its nominated upstream, and has a slew of NMUs. I'm not sure what the etiquette is here. Utkarsh said he'd take a look in the next few days.

Utkarsh, can you have a look? I unsubscribed ~ubuntu-sponsors. Please resubscribe ~ubuntu-sponsors if you want another sponsor to look at it.