pkexecとgksu / gksudoを使用する場合
pkexecはこの構成可能性を利用しませんが、PolicyKitはより構成可能です。また、pkexecは、開始されるプログラムの完全なパスをユーザーに表示します。これにより、ユーザーは何が起こるかをもう少し確信できます。 PolicyKitのいわゆる「ポリシー」を使用して、より高度な設定を行うことができます。たとえば、パスワードを記憶する必要があるかどうか。
pkexecマニュアルから得たもの：
PROGRAMが実行する環境は、LD_LIBRARY_PATHまたは同様のメカニズムを介したコードの挿入を回避するために、最小限の既知の安全な環境に設定されます。さらに、PKEXEC_UID環境変数は、pkexecを呼び出すプロセスのユーザーIDに設定されます。その結果、pkexecでは、たとえば$ DISPLAY環境変数が設定されていないため、別のユーザーとしてのX11アプリケーション。
pkexecマニュアルのポリシーまたはアクション定義の詳細：
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).
Sudoを使用すると、Sudoのコンテキストで呼び出し側環境を保持またはリセットするかどうかについて、ユーザーごとおよびプログラムごとにポリシーを設定できます。 env_resetポリシーはデフォルトで設定されています。
明示的に設定しないと、pkexecを使用してグラフィカルアプリケーションを実行できません。これは単に環境リセットの結果であるため、これは明らかにSudoにも当てはまります。ただし、pkexecもSudoも、rootとして実行されている悪意のあるアプリケーションがディスプレイマネージャーまたはユーザーのX11-cookieファイルから必要な情報をすべて取得するのを防ぐことはできません。後者、またはその両方は、状況に応じて、非ルートアプリケーションによって実行される場合もあります。
須藤は、ユーザーの明示的なリストを必要としません。一般に、ユーザーグループの一覧表示、またはすべてのユーザーのアクセス許可の設定を行うこともできます。 target_pwディレクティブを使用すると、これらのユーザーは、アプリケーションを実行したいコンテキスト（root）のユーザーの資格情報で認証できます。それとは別に、同様に伝統的なsu（su/gtksu/kdesu）プログラムを使用して、特別な設定なしでまったく同じことを行うことができます。
Sudoでも、ユーザーは指定された時間の間、認証されたままになります。このオプションにはタイムアウトという名前が付けられ、グローバル、ユーザーごと、またはアプリケーションごとに構成できます。認証は、ttyごとに保持することも、ユーザーごとにグローバルに保持することもできます。
PkexecはPROGRAMに渡された引数の検証を行わない場合がありますが、Sudoには実際にこの機能があります。ただし、これは簡単に台無しにできますが、通常は行われません。
Pkexecを使用してプログラムを実行する方法を少し調整できます。アイコン、表示するテキスト、ローカリゼーションなどもあります。状況に応じて、これは確かに気の利いたものになります。悲しいことに、誰かがこの機能のために車輪を再発明する必要性を感じたと。これはおそらく、グラフィカルなgtksudo/kdesuラッパーに入れるものです。
Policykitは、集中化された構成フレームワークにすぎません。残念ながら、きれいなものではありません。 PKのXMLファイルは、アプリがネイティブにバイナリファイルを短く提供できるものよりもはるかに複雑です。そして、誰もバイナリを使用するのにそんなにお金がかからないでしょう...ああgconf ...気にしないでください。
pkexecがSudoおよびそのフロントエンドとどのように異なるか、いくつかの点があります。
- 明示的に設定しない限り、
pkexecを介してグラフィカルアプリケーションを実行することはできません。 pkexec：アイコン、表示するテキスト、パスワードを記憶するかどうか、グラフィカルに実行できるようにするかどうかなど、プログラムの実行方法を少し調整できます。Sudoを使用して、スーパーユーザーとして「実行」を実行できます（sudoersにadminとしてリストする必要があります）。gksudoはパスワードを要求するときにキーボード、マウス、フォーカスをロックしますが、pkexecはロックしません。どちらの場合も キーストロークはスニッフィング可能ですが です。pkexecを使用すると、少しサニタイズされた環境で作業できます。
例としてみてください：
cd /etc/init.d
Sudo cat README
# and now the same with pkexec
pkexec cat README
# Nice, huh?