kde-l10n-fr 4:4.14.0-1 / usr / share / doc / kde / HTML / fr / PolicyKit-kde / howitworks.docbook

<chapter id="howitworks">
<title
>Comment cela fonctionne</title>

<sect1 id="howitworks-overview">
<title
>Aperçu</title>

<para
>PolicyKit fonctionne simplement, mais cela nécessite quelques changements conceptuels pour les applications qui souhaitent l'utiliser afin de demander des mots de passe.</para>
</sect1>

<sect1 id="howitworks-problem">
<title
>Le problème</title>

<para
>Dans les applications graphiques, la méthode classique pour obtenir les privilèges du superutilisateur est de lancer l'application en tant que root, mais cela crée plusieurs risques de sécurité sérieux et ne permet pas de cartographier correctement les actions. Il n'y a pas de manière de séparer l'action installation-de-paquet de l'action mise-à-jour-du-système. Tous les utilisateurs voulant utiliser l'application graphique doivent également disposer du mot de passe root. Une autre approche commune est d'utiliser sudo, mais une fois que vous avez lancé une application avec sudo vous disposerez de tous les droits que l'utilisateur root détient. Si une application graphique contient par exemple une fenêtre de sélection de fichiers, celle-ci fonctionne en tant que root, ce qui signifie que l'utilisateur pourrait être en mesure de supprimer n'importe quel fichier de l'ordinateur ou même de fouiller dans les fichiers des autres utilisateurs. </para>
</sect1>

<sect1 id="howitworks-solution">
<title
>La solution</title>

<para
>Avec PolicyKit ce problème est résolu. L'application en question n'a besoin que d'isoler le code privilégié dans une autre application, souvent appelé l'assistant (qui ne disposera pas d'interface graphique) et de cartographier les actions désirées dans un fichier <quote
>.policy</quote
>. PolicyKit chargera ensuite ce fichier et peut maintenant authentifier les applications pour qu'elles utilisent ces actions. L'utilisation d'applications &DBus; est la meilleure manière, si ce n'est la seule, de permettre à une application assistant de fonctionner avec des privilèges root.</para>

<para
>Avec cette architecture, l'application graphique appelle une action de l'application assistante via &DBus;, qui lancera l'assistant avec les privilèges root, en l'informant quelle action a été requise et par quelle application. L'assistant appellera ensuite l'agent PolicyKit afin de vérifier si l'application peut effectuer la tâche donnée. Si l'assistant voit que l'application graphique ne dispose pas de droits suffisants, celle-ci devra demander à PolicyKit l'obtention d'une autorisation.</para>

<para
>Lorsque PolicyKit reçoit une requête afin d'obtenir une autorisation, elle utilise un agent disponible, qui peut par exemple être &policykit-kde; s'il est disponible. Après une authentification réussie, l'interface graphique doit de nouveau appeler l'assistant afin de répéter la même opération.</para>
</sect1>

</chapter>