Package: policykit-1
Version: 0.105-28
Severity: important
I notice that the polkit-agent-helper in unstable has been moved into
/usr/libexec. I have not reproduced this myself (I'm currently running
the experimental version), but I think this will cause upgrade issues
similar to #699447.
During upgrades, typically a polkit agent (an implementation of
polkit-1-auth-agent) will already be running, either integrated into
a desktop shell like GNOME Shell, gnome-flashback or phosh, or as a
separate standalone program like polkit-kde-agent-1 or lxpolkit. Until
the next reboot or logout/login, the agent will already have the old
libpolkit-agent-1.so.0 in its address space, which means that when it
tries to authenticate the user, that copy of libpolkit-agent-1.so.0
will try to run the agent-helper by its old path. In experimental, we
solved #699447 by creating a symlink at the old path of the agent-helper,
pointing to its new path.
This would also cause upgrade issues if we ever get as far as upgrading
to the latest upstream polkit as shipped in experimental, either
as-is (with JavaScript rules) or with the .pkla backend patched back
in. In the latest upstream polkit, the agent-helper has been moved into
${prefix}/lib/polkit-1 (again, see #699447), independent of ${libexecdir}
or even ${libdir}. As a result, I think it would be a good idea to put
the agent-helper in the same location in bullseye that it already has
in experimental, with the same compat symlink, so that we don't have to
have a double transition. We can drop the compat symlink after bullseye
is released.
Concrete steps to achieve that would be something like this:
- d/rules: set --libexecdir=/usr/lib/polkit-1
- *.install, postinst, polkit.service: adjust to that path
- cherry-pick be4fed1f from experimental to create the compat symlink
Alternatively, if we strongly prefer /usr/libexec, we should talk
to upstream about reverting 6fbcc6cd (which unhelpfully does not say
anything about why the change was made), carry out a transition in both
bullseye and experimental, and create a compat symlink similar to be4fed1f
(for completeness, we might as well create compat symlinks for *both*
old paths if we go this route).
In the longer term, if we want to continue to have a polkit version that
obeys .pkla files and does not depend on mozjs, I think we might get
better results by taking the latest upstream version (currently 0.116),
patching it to disable the JavaScript backend, patching in the old .pkla
backend from v0.105, and calling the resulting version "0.105+0.116-1" or
something like that: the patch series in debian/patches is increasingly
unwieldy, and despite my best efforts, probably still doesn't include
all the fixes from 0.116 (see also #946231). That's out of scope for
this bug, but I would prefer to resolve this bug in a direction that
will not save up trouble for us later on if we do that in future.
Of course, the best long-term solution would be if the Debian and upstream
maintainers of polkit can agree on a backend that we are all happy with,
preferably one that does not have mozjs's frequent API breaks - but this
would require some discussion of what the various maintainers involved
see as the requirements for that backend, and I don't feel that I can
represent the Debian maintainers in this, because I am not the one with
a strong opinion about the configuration language.
smcv
