When to use pkexec vs. gksu/gksudo?
PolicyKit is more configurable, though pkexec doesn't make use of this configurability. Also, pkexec show the user the full path of the program that will be started, to that the user is a bit more sure what will happen. The so-called 'policies` of PolicyKit can be used to set more advances settings. For example, whether the password should be remembered.
Something I got from the pkexec manual:
The environment that PROGRAM will run it, will be set to a minimal known and safe environment in order to avoid injecting code through LD_LIBRARY_PATH or similar mechanisms. In addition the PKEXEC_UID environment variable is set to the user id of the process invoking pkexec. As a result, pkexec will not allow you to run e.g. X11 applications as another user since the $DISPLAY environment variable is not set.
More information on policies or action definitions from the pkexec manual:
To specify what kind of authorization is needed to execute the program /usr/bin/pk-example-frobnicate as another user, simply write an action definition file like this <?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> <vendor>Examples for the PolicyKit Project</vendor> <vendor_url>http://hal.freedesktop.org/docs/PolicyKit/</vendor_url> <action id="org.freedesktop.policykit.example.pkexec.run-frobnicate"> <description>Run the PolicyKit example program Frobnicate</description> <description xml:lang="da">Kør PolicyKit eksemplet Frobnicate</description> <message>Authentication is required to run the PolicyKit example program Frobnicate</message> <message xml:lang="da">Autorisering er påkrævet for at afvikle PolicyKit eksemplet Frobnicate</message> <icon_name>audio-x-generic</icon_name> <defaults> <allow_any>no</allow_any> <allow_inactive>no</allow_inactive> <allow_active>auth_self_keep</allow_active> </defaults> <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/pk-example-frobnicate</annotate> </action> </policyconfig> and drop it in the /usr/share/polkit-1/actions directory under a suitable name (e.g. matching the namespace of the action). Note that in addition to specifying the program, the authentication message, description, icon and defaults can be specified. For example, for the action defined above, the following authentication dialog will be shown: [IMAGE][2] +----------------------------------------------------------+ | Authenticate [X] | +----------------------------------------------------------+ | | | [Icon] Authentication is required to run the PolicyKit | | example program Frobnicate | | | | An application is attempting to perform an | | action that requires privileges. Authentication | | is required to perform this action. | | | | Password: [__________________________________] | | | | [V] Details: | | Command: /usr/bin/pk-example-frobnicate | | Run As: Super User (root) | | Action: org.fd.pk.example.pkexec.run-frobnicate | | Vendor: Examples for the PolicyKit Project | | | | [Cancel] [Authenticate] | +----------------------------------------------------------+ If the user is using the da_DK locale, the dialog looks like this: [IMAGE][3] +----------------------------------------------------------+ | Autorisering [X] | +----------------------------------------------------------+ | | | [Icon] Autorisering er påkrævet for at afvikle | | PolicyKit eksemplet Frobnicate | | | | Et program forsøger at udføre en handling der | | kræver privilegier. Autorisering er påkrævet. | | | | Kodeord: [___________________________________] | | | | [V] Detaljer: | | Bruger: Super User (root) | | Program: /usr/bin/pk-example-frobnicate | | Handling: org.fd.pk.example.pkexec.run-frobnicate | | Vendor: Examples for the PolicyKit Project | | | | [Annullér] [Autorisering] | +----------------------------------------------------------+ Note that pkexec does no validation of the ARGUMENTS passed to PROGRAM. In the normal case (where administrator authentication is required every time pkexec is used), this is not a problem since if the user is an administrator he might as well just run pkexec bash to get root. However, if an action is used for which the user can retain authorization (or if the user is implicitly authorized), such as with pk-example-frobnicate above, this could be a security hole. Therefore, as a rule of thumb, programs for which the default required authorization is changed, should never implicitly trust user input (e.g. like any other well-written suid program).
With sudo you can set per user and per program policies about wether to retain or reset the callers environment in the context of sudo. The env_reset policy is set by default.
You can't run graphical applications via pkexec without explicitly configuring it to do so. Because this is merely a result of the environment reset this is obviously true for sudo as well. Note however thet neither pkexec nor sudo can prevent a malevolent application running as root to retrieve all neccessary information from the display managers or the users X11-cookie file. The latter, both or similiar, may even be done by non root applications depending on circumstances.
Sudo does not require explicit listings of users. Listing any user group or even setting a permission for all users in general can be done. The target_pw directive allows those users to authenticate with the credentials of the user in whoose context they want to run an application, i.e. root. Apart from that the equally traditional su (su / gtksu / kdesu) program can be used to do the very same without special configuration.
sudo, too, allows the user to remain authenticated for a specified time. The option is named timeout, configurable globally, per user, or per application. Authentication can be retained per tty or globally per user.
While pkexec may do no validation of the ARGUMENTS passed to PROGRAM, sudo does indeed have this feature. Admitted though, you can easily mess up with this, and it is normally not done.
You can tweak a little how you want programs to be run via pkexec: icon, text to display, you can even have localization stuff and all that. Depending on circumstances this can be nifty indeed. Sad though, that someone felt the need to reinvent the wheel for this feature. This would probably be something to put into the graphical gtksudo/kdesu wrappers.
Policykit is only a centralized configuration framework then. Unfortunately not a pretty one. PKs XML-Files are way more complicated than anything an app could provide natively short of binary files. And no one would be so looney to use binary ... oh gconf ... never mind.
A few things how pkexec is different from sudo and its frontends:
- You can't run graphical applications via
pkexecwithout explicitly configuring it to do so. - You can tweak a little how you want programs to be run via
pkexec: icon, text to display, whether to remember the password or not, whether to allow it to run graphically and some more. - Anybody can run "Run as" a superuser (provided they can authenticate as such), with
sudoyou have to be listed in thesudoersfile as admin. gksudolocks the keyboard, mouse, and focus when asking for a password,pkexecdoesn't. In both cases the keystrokes are sniffable though.- With
pkexecyou work in a slightly more sanitized environment.
Try for example:
cd /etc/init.d
sudo cat README
# and now the same with pkexec
pkexec cat README
# nice, huh?