Avec sudo, vous pouvez définir des règles par utilisateur et par programme pour conserver ou réinitialiser l'environnement de l'appelant dans le contexte de sudo. La politique env_reset est définie par défaut.
Vous ne pouvez pas exécuter d'applications graphiques via pkexec sans le configurer explicitement pour le faire. Comme il s'agit simplement d'un résultat de la réinitialisation de l'environnement, cela est évidemment vrai aussi pour sudo. Notez cependant que ni pkexec ni sudo ne peuvent empêcher une application malveillante s'exécutant en tant que root de récupérer toutes les informations nécessaires à partir des gestionnaires d'affichage ou du fichier X11-cookie de l'utilisateur. Cette dernière opération, ou des opérations similaires, peut même être effectuée par des applications non root, selon les circonstances.
Sudo ne requiert pas de listes explicites d'utilisateurs. Il est possible de lister n'importe quel groupe d'utilisateurs ou même de définir une permission pour tous les utilisateurs en général. La directive target_pw permet à ces utilisateurs de s'authentifier avec les informations d'identification de l'utilisateur dans le contexte duquel ils veulent exécuter une application, c'est-à-dire root. En outre, le tout aussi traditionnel programme su (su / gtksu / kdesu) peut être utilisé pour faire la même chose sans configuration particulière.
sudo, également, permet à l'utilisateur de rester authentifié pendant une durée déterminée. L'option est nommée timeout, configurable globalement, par utilisateur, ou par application. L'authentification peut être conservée par tty ou globalement par utilisateur.
Alors que pkexec ne fait pas de validation des ARGUMENTS passés à PROGRAM, sudo dispose effectivement de cette fonctionnalité. Cependant, il faut admettre que vous pouvez facilement vous tromper avec cela, et cela n'est normalement pas fait.
Vous pouvez modifier un peu la façon dont vous voulez que les programmes soient lancés via pkexec : icône, texte à afficher, vous pouvez même avoir des trucs de localisation et tout ça. Selon les circonstances, cela peut être très pratique. Il est cependant triste que quelqu'un ait ressenti le besoin de réinventer la roue pour cette fonctionnalité. Ce serait probablement quelque chose à mettre dans les wrappers graphiques de gtksudo/kdesu.
Policykit n'est donc qu'un cadre de configuration centralisé. Malheureusement pas un joli cadre. Les fichiers XML de Policykit sont bien plus compliqués que tout ce qu'une application pourrait fournir nativement, à part des fichiers binaires. Et personne ne serait assez fou pour utiliser des fichiers binaires ... oh gconf ... peu importe.