#1136196 pkexec: allow_gui annotation no longer preserves DISPLAY/XAUTHORITY

Package:
pkexec
Source:
pkexec
Description:
run commands as another user with polkit authorization
Submitter:
Fabio Fantoni
Date:
2026-07-12 20:57:01 UTC
Severity:
normal
#1136196#5
Date:
2026-05-10 18:03:34 UTC
From:
To:
The org.freedesktop.policykit.exec.allow_gui annotation does not
have the documented effect of preserving $DISPLAY and $XAUTHORITY
in the target process environment. GUI programs launched via
pkexec that rely on allow_gui (e.g. bleachbit-root) fail to start
with "cannot open display" / similar.

Reproducer (X11 session, Cinnamon):

1. /usr/share/polkit-1/actions/org.bleachbit.policy contains:
     <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/bleachbit</annotate>
     <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>

2. pkaction --action-id org.bleachbit --verbose confirms both
   annotations are registered, including allow_gui = true.

3. pkexec /usr/bin/bleachbit fails with:
     RuntimeError: GTK is required but not available:
     No DISPLAY or WAYLAND_DISPLAY environment variable set

4. Workaround that confirms env stripping is the cause:
     pkexec env DISPLAY="$DISPLAY" XAUTHORITY="$XAUTHORITY" \
       /usr/bin/bleachbit
   starts normally.

Expected, per pkexec(1):
  "These two variables [DISPLAY, XAUTHORITY] will be retained if
  the org.freedesktop.policykit.exec.allow_gui annotation on an
  action is set to a nonempty value"

I have not bisected against earlier Debian pkexec versions, so I
cannot confirm whether this is a regression or a longer-standing
issue.

#1136196#10
Date:
2026-07-12 18:19:49 UTC
From:
To:

I found the root cause of this issue.

Since polkit 127, pkexec resolves the program path with realpath(3)
*before* matching it against the org.freedesktop.policykit.exec.path
annotations. This comes from upstream commit
9aa43e089d870a8ee695e625237c5b731b250678 ("pkexec: Use realpath when
comparing org.freedesktop.policykit.exec.path"), which was meant to
handle usrmerge aliasing (/bin/foo vs /usr/bin/foo, upstream issue
polkit-org/polkit#194).

The annotation match in find_action_for_path() is an exact string
comparison, so if the annotated path is a symlink the resolved path no
longer matches, the action is silently not found, and pkexec falls back
to the implicit action. As a consequence allow_gui is not applied
(DISPLAY and XAUTHORITY get stripped), and any custom defaults/message
of the action are ignored as well.

In my case: /usr/bin/bleachbit is a symlink to
/usr/share/bleachbit/bleachbit.py, so the org.bleachbit action (which
has allow_gui=true, as shown by pkaction) is no longer matched.
allow_gui itself is not broken: the same annotation works if the
annotated path is not a symlink. This also explains why manually passing
the variables with "pkexec env DISPLAY=... XAUTHORITY=..." works.

So the behavior contradicts both the pkexec(1) manpage (which still says
DISPLAY/XAUTHORITY are retained when allow_gui is set) and the
least-surprise expectation for packages whose entry point in /usr/bin is
a symlink (fairly common for interpreted programs). The upstream commit
message itself warned "a review of your <annotate
key=\"org.freedesktop.policykit.exec.path\"> actions might be in order",
but nothing was documented in NEWS or the manpage, and affected actions
fail silently.

Possible fixes on the polkit side:
- match the annotation against both the pre-realpath absolute path and
the resolved one (or also canonicalize the annotation value before
comparing), or
- at minimum document the behavior change in pkexec(1)/NEWS so packages
know they must annotate the canonical path.

I have worked around it in bleachbit by shipping a second action with
the resolved path (keeping the old one for pkexec < 127), which will be
in bleachbit 6.0.2-1. Other packages with symlinked exec.path
annotations are likely affected in the same way.

Please consider forwarding this upstream
(https://github.com/polkit-org/polkit/issues).

#1136196#17
Date:
2026-07-12 19:48:22 UTC
From:
To:
Hi Fabio,

thanks for the detailed bug report and analysis.

Am 12.07.26 um 20:19 schrieb Fabio Fantoni:

We usually prefer if bug reporters forward issues to upstream
themselves, just in case upstream has more questions or want's you to
test patches etc. (so we as Debian maintainer don't have to play bug proxy)

And given you basically did all the work in tracking this down, it would
also be good if this was attributed to you properly.

Regards
Michael

#1136196#22
Date:
2026-07-12 20:55:27 UTC
From:
To:
Il 12/07/2026 21:48, Michael Biebl ha scritto:
Sorry, unfortunately, due to various unforeseen circumstances, including
this one, out of four "small" packaging jobs I wanted to do today in 3
hours total, I was only able to complete one :( (bleachbit). Due to lack
of time, upstream I only filed a quick issue on bleachbit
(https://github.com/bleachbit/bleachbit/issues/2195) and only suggested
posting upstream here.
I recently started using LLM, and it helps me save time and achieve more
results on many things, but I still have to spend a lot of time
preparing local repos and test environments, explain what do, checking
them, and guiding and correct them so they have a good chance of
producing something useful and good. However, they often make mistakes
and can waste time. And since I can do more with them than I would
without them (in total), I'm getting into the "bad habit" of debugging
and possibly fixing too many of the things I find.
I thought about having Claude prepare the text for open the issue
upstream, but then, in the end, checking what he generates, responding
later, testing any upstream solutions, etc., I risked starting another
thing that could take a lot of time.
I'll see in the next days if I'm not too busy on other things if
continue also this.