This is a feature request for a --title command line option to display a friendly name in the policykit authentication dialog instead of the full application binary's path. Use case: pkexec --title "Cool Calculator" /usr/bin/coolcalc
Some more context: We'd like to write a "pkexecdesktop" wrapper which is able to run the program in a .desktop file as root, with something like pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY pkexec --title "(translated Name= from .desktop)" (Exec= from .desktop) With that we can finally get rid of the remaining usage of gksu, to provide a consistent UI.
David, does that sound ok to you? I can work on a patch for it, but would like to discuss the design first.
It's a great idea to discuss the design first! Did you try using the org.freedesktop.policykit.exec.path annotation http://hal.freedesktop.org/docs/polkit/pkexec.1.html Looks to me like that's exactly what you need - just include a .policy file along with the few binaries that you expect to launch via pkexec(1).
(In reply to comment #0) > This is a feature request for a --title command line option to display a > friendly name in the policykit authentication dialog instead of the full > application binary's path. > > Use case: > > pkexec --title "Cool Calculator" /usr/bin/coolcalc Btw, note that pkexec(1) will not launch X11 applications running as root (by design). So unless /usr/bin/coolcalc is a curses app or something, this example is not very useful.
Right...my example didn't exactly illustrate what we intend to do, which is to run an X11 application using the example Martin provided. I tried creating a policy file, and it works as intended. This doesn't exactly provide the functionality we are looking for though, as we're actually using pkexec to run env in order to set the required environment variables necessary to run an X11 app (which pkexec doesn't support).
Summary from IRC discussion: * Using --title/--programname is spoofable, so we don't want that. * We can introduce a new org.freedesktop.policykit.exec.allow_gui flag in the .policy file, and then use its <message> field to produce a proper message. * For now this flag would preserve $DISPLAY and $XAUTHORITY, like in http://cgit.freedesktop.org/PolicyKit/tree/src/programs/pkexec.c#n411
While I was playing with this I noticed that polkitd segfaults when there is a .policy file without a <message> field. I fixed that in trunk (675e4337d7f83ffaf9612cadf7f365c545c51243) while I was at it, straightforward patch. Please LART me if that was inappropriate.
Created attachment 48572 [details] [review] pkexec: Support running X11 apps It works nicely with this patch. It checks whether org.freedesktop.policykit.exec.allow_gui is set to any nonzero value, which avoids having to check for particular variations of "yes", "True", etc. I also updated the documentation, but tried to not encourage using this too much. With that we can finally move the remaining few root X11 apps to pkexec, which will provide a consistent and also accessible auth UI, and make the auth dialogs less spoofable than gksu. Tested with this .policy file: --------------- 8< -------------- ?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"> <policyconfig> <action id="com.ubuntu.pkexec.synaptic"> <message>Authentication is required to run the Synaptic package manager</message> <icon_name>synaptic</icon_name> <defaults> <allow_any>auth_admin</allow_any> <allow_inactive>auth_admin</allow_inactive> <allow_active>auth_admin</allow_active> </defaults> <annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/synaptic</annotate> <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate> </action> </policyconfig> --------------- 8< -------------- As before, $DISPLAY and $XAUTHORITY are not kept if the contents of the tag is empty, or the annotation is not set at all.
*** Bug 23673 has been marked as a duplicate of this bug. ***
Committed, thanks!
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.