Bug 51623

Summary: graphical applications started with pkexec do not find a X session to connect
Product: PolicyKit Reporter: FabiB <fabydesu>
Component: daemonAssignee: Peter Wu <peter>
Status: RESOLVED FIXED QA Contact: David Zeuthen (not reading bugmail) <zeuthen>
Severity: blocker    
Priority: medium CC: daniels_policykit_bugzilla_adress, ossi, peter, psusi
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: Create $XAUTHORITY from $HOME if unset

Description FabiB 2012-07-01 10:20:38 UTC
With a KDE Desktop (dont know if it is the same with gnome) you can run

pkexec whoami

with no problems but if you try a graphical application it will fail. like partitionmanager

pkexec partitionmanager
partitionmanager-bin: cannot connect to X server
Comment 1 David Zeuthen (not reading bugmail) 2012-07-01 13:09:14 UTC
You a .policy file for the binary with an allow_gui annotation for this to work, see http://www.freedesktop.org/software/polkit/docs/latest/pkexec.1.html for details
Comment 2 FabiB 2012-07-19 13:21:41 UTC
thank you for this information
but in this case, wouldnt it be better to have a graphical error message which sais that this application is not allowed to run as root?
Comment 3 Peter Wu 2012-09-08 22:52:09 UTC
Created attachment 66854 [details] [review]
Create $XAUTHORITY from $HOME if unset

I have just checked in a Ubuntu 12.04 Live CD and I see that XAUTHORITY is set. This is not the case for KDE. The attached patch sets XAUTHORITY to $HOME/.Xauthority if it was not set before and thus allowing programs like gparted to work.
Comment 4 Peter Wu 2012-09-08 22:59:39 UTC
*** Bug 49707 has been marked as a duplicate of this bug. ***
Comment 5 David Zeuthen (not reading bugmail) 2012-09-09 15:51:39 UTC
It's not pkexec(1)'s job to set XAUTHORITY
Comment 6 Peter Wu 2012-09-10 16:39:30 UTC
I submitted a patch for kdm but it got rejected there too.

> > The fix is declined for polkit as "It's not pkexec(1)'s job to set XAUTHORITY"
> > https://bugs.freedesktop.org/show_bug.cgi?id=51623
> >
> tell him to get a clue. the program which changes the user context must
> also adjust relevant environment variables, which includes setting them
> in the first place when they start to deviate from the default.

He has a point. Since pkexec already passes DISPLAY, why would you choose to ignore XAUTHORITY? I say ignore because of the user change, the interpreted XAUTHORITY variable also changes, and the goal of use_gui is actually letting the program display itself on the user's screen.

> It's not pkexec(1)'s job to set XAUTHORITY
pkexec(1) does set it for child programs, so it should make sure that the child receives sane values.
Comment 7 David Zeuthen (not reading bugmail) 2012-09-10 17:15:41 UTC
Please read the source before commenting: pkexec(1) will preserve the value of XAUTHORITY if the appropriate annotation is used. Stop reopening this bug.
Comment 8 Oswald Buddenhagen 2012-09-20 22:43:31 UTC
david, you are simply WRONG. X defines that XAUTHORITY defaults to ~/.Xauthority if it is not set. therefore, "preserving" the value of the variable implies *actively setting* it upon changing the user identity. pkexec contains no such code, and is thereofore broken by definition. period.

not to mention that simply passing on a reference to the calling user's xauth file is a rather inelegant solution (it relies on the target app running as root, potentially gives access to way too many displays, and opens the door for accidental modifications). study pam_xauth to see how to do it *right*.

if you close this as NOTABUG again you'll make a laughing stock of yourself.
Comment 9 David Zeuthen (not reading bugmail) 2012-12-19 19:40:39 UTC
OK. I still don't like how XAUTHORITY works but that's somewhat unimportant since it does work the way you describe. I've added a patch loosely based on the one in comment 3:

 http://cgit.freedesktop.org/polkit/commit/?id=d6acecdd0ebb42e28ff28e04e0207cb01fa20910

Closing.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.