Indications from the upstream issue are that removing sentry from the snap makes this stop happening. Would be good if this could be fixed on our side, as other electron application developers may also want to use it.
“Inhibit() creates an inhibition lock. It takes four parameters: What, Who, Why and Mode. “What” is one or more of “shutdown”, “sleep”, “idle”, “handle-power-key”, “handle-suspend-key”, “handle-hibernate-key”, “handle-lid-switch”, separated by colons, for inhibiting poweroff/reboot, suspend/hibernate, the automatic idle logic, or hardware key handling. “Who” should be a short human readable string identifying the application taking the lock. “Why” should be a short human readable string identifying the reason why the lock is taken. Finally, “Mode” is either “block” or “delay” which encodes whether the inhibit shall be consider mandatory or whether it should just delay the operation to a certain maximum time. The call returns a file descriptor. The lock is released the moment this file descriptor (and all its duplicates) are closed. For more information on the inhibition logic see Inhibitor Locks.”
As such, this Inhibit is different from screen-inhibit. It could probably be added to the shutdown interface, but that is not a perfect fit because the shutdown interface is about, well, shutting down and this DBus api is about preventing shutting down. Preventing shutting down allows the snap the ability to prevent booting into a new kernel, core, etc so an application using this interface would be considered privileged. I’m honestly quite surprised that an electron app or a desktop app is in the business of inhibiting shutdown-- this sounds like a mis-feature or a bug in these applications. Can you detail the justification for inhibiting shutdown/etc?
Also, does the denial cause the snap to crash or does it happily keep running (I would hope the latter-- seems like policykit could conceivably block this (separate from apparmor) and that should not be a fatal error.
It would die. Upstream have removed the sentry call to prevent it crashing. I have had some other applications which die similarly but don’t use sentry. I saw it this week with an electron app called wewechat I snapped.
is this behaviour of the apps a misguided attempt to ensure they get shut down properly to prevent them losing data? kinda like Windows’ behaviour where it will signal all applications to close and then wait for them all to cleanly exit before rebooting or turning off with a notice “The following applicaitons are preventing shutdown”.
This is buggy code. It should fail gracefully as there are other things that might prevent its access besides an AppArmor denial due to being packaged as a snap (as mentioned, a deb, rpm, whatever would crash if there was a polkit denial for this (eg, see /usr/share/polkit-1/actions/org.freedesktop.login1.policy). I would argue snaps should not typically be allowed this.
That said, because we know there is polkit, one could argue that on classic distro where polkit is a thing (polkit does not exist on Ubuntu Core devices yet), we could allow the access. I would argue we should not since the distro/admin may have configured the system to allow access for certain users/groups, and since polkit doesn’t atm understand snaps, on these systems if we allowed the access the snap would be able to prevent shutdowns/reboot/etc when run under these users/groups. This would be a manually connected interface anyway.
Put more clearly-- electron, sentry, whatever needs to handle the denial gracefully. This will improve their robustness outside of snaps which would be good for them. If there is a legitimate use of the DBus api, we can consider adding an interface, but IMO we don’t want to allow the access simply because an application is coded incorrectly when facing a denial.
