polkit (Français)

État de la traduction: Cet article est la version francophone de polkit. Date de la dernière traduction: 2021-12-27. Vous pouvez aider à synchroniser la traduction s'il y a eu des changements dans la version anglaise.

Related articles

• General troubleshooting (Français)#Permissions de session
• Sudo (Français)
• Users and groups (Français)

Traduit de la page d'accueil de polkit :

polkit est une boîte à outils au niveau application pour définir et gérer la politique qui permet aux processus non privilégiés de parler aux processus privilégiés : Il s'agit d'un cadre permettant de centraliser le processus de prise de décision concernant l'octroi de l'accès aux opérations privilégiées pour les applications non privilégiées.

Polkit est utilisé pour contrôler les privilèges à l'échelle du système. Il fournit un moyen organisé pour les processus non privilégiés de communiquer avec les processus privilégiés. Contrairement à des systèmes tels que sudo, il n'accorde pas l'autorisation root à un processus entier, mais permet plutôt un niveau de contrôle plus fin de la politique système centralisée.

Polkit fonctionne en délimitant des actions distinctes, par exemple l'exécution de GParted, et en délimitant les utilisateurs par groupe ou par nom, par exemple les membres du groupe wheel. Il définit ensuite comment - le cas échéant - ces utilisateurs sont autorisés à effectuer ces actions, par exemple en s'identifiant comme membres du groupe en tapant leur mot de passe.

Installation

Installez le paquet polkit.

Agents d'authentification

Un agent d'authentification est utilisé pour que l'utilisateur d'une session prouve qu'il est bien l'utilisateur (en s'authentifiant en tant qu'utilisateur) ou un utilisateur administratif (en s'authentifiant en tant qu'administrateur). Le paquet polkit contient un agent d'authentification textuel appelé 'pkttyagent', qui est utilisé comme solution de repli générale.

Si vous utilisez un environnement graphique, assurez-vous qu'un agent d'authentification graphique est installé et démarré automatiquement à la connexion.

Cinnamon, Deepin, GNOME, GNOME Flashback, KDE, LXDE, LXQt, MATE, theShell et Xfce ont déjà un agent d'authentification. Dans les autres environnements de bureau, vous devez choisir l'une des implémentations suivantes :

• lxqt-policykit, qui fournit /usr/bin/lxqt-policykit-agent}.
• lxsession ou lxsession-gtk3, qui fournit /usr/bin/lxpolkit.
• mate-polkit, qui fournit /usr/lib/mate-polkit/polkit-mate-authentication-agent-1
• polkit-efl-git^AUR, qui fournit /usr/bin/polkit-efl-authentification-agent-1.
• polkit-gnome, qui fournit /usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1
• polkit-kde-agent, qui fournit /usr/lib/polkit-kde-authentification-agent-1.
• ts-polkitagent^AUR, qui fournit /usr/lib/ts-polkitagent.
• xfce-polkit^AUR ou xfce-polkit-git^AUR, qui fournit /usr/lib/xfce-polkit/xfce-polkit.
• polkit-dumb-agent-git^AUR, agent indépendant de bureau minimaliste qui fournit /usr/bin/polkit-dumb-agent.

Configuration

Attention: Ne modifiez pas les fichiers de permission par défaut des paquets, car ils peuvent être écrasés lors des mises à jour des paquets.

Les définitions de Polkit peuvent être divisées en deux sortes :

• Les Actions sont définies dans des fichiers XML .policy situés dans /usr/share/polkit-1/actions. Chaque action est associée à un ensemble de permissions par défaut (par exemple, vous devez vous identifier en tant qu'administrateur pour utiliser l'action GParted). Les valeurs par défaut peuvent être remplacées mais éditer les fichiers d'actions n'est PAS la bonne méthode.
• Les règles d'autorisation sont définies dans les fichiers .rules JavaScript. On les trouve à deux endroits : Les paquets tiers peuvent utiliser /usr/share/polkit-1/rules.d (bien que peu, voire aucun, ne le fasse) et /etc/polkit-1/rules.d est destiné à la configuration locale.

Polkit fonctionne au-dessus des systèmes de permissions existants dans Linux - appartenance à un groupe, statut d'administrateur - il ne les remplace pas. Les fichiers .rules désignent un sous-ensemble d'utilisateurs, font référence à une (ou plusieurs) des actions spécifiées dans les fichiers actions, et déterminent avec quelles restrictions ces actions peuvent être effectuées par ces utilisateurs. Par exemple, un fichier de règles peut annuler l'obligation par défaut pour tous les utilisateurs de s'authentifier en tant qu'administrateur lorsqu'ils utilisent GParted, en déterminant qu'un utilisateur spécifique n'a pas besoin de le faire. Un autre exemple : Un certain utilisateur n'est pas du tout autorisé à utiliser GParted.

Note: Cela n'empêche pas d'exécuter GParted par des moyens qui ne respectent pas polkit, comme la ligne de commande. Par conséquent, polkit devrait être utilisé pour élargir l'accès aux services privilégiés pour les utilisateurs non privilégiés, plutôt que d'essayer de restreindre les droits des utilisateurs (semi-)privilégiés. Pour des raisons de sécurité, sudoers reste la meilleure solution.

Actions

Astuce: Pour afficher les actions de Policykit dans une interface graphique, installez le paquet polkit-explorer-git^AUR.

Les actions disponibles via polkit dépendent des paquets que vous avez installés. Certaines sont utilisées dans plusieurs environnements de bureau (org.freedesktop.*), certaines sont spécifiques à un DE (org.gnome.*) et d'autres sont spécifiques à un seul programme (org.gnome.gparted.policy). La commande pkaction liste toutes les actions définies dans /usr/share/polkit-1/actions} pour une référence rapide.

Pour avoir une idée de ce que polkit peut faire, voici quelques groupes d'actions couramment utilisés :

• Les actions de systemd-logind (org.freedesktop.login1.policy) régies par polkit comprennent la mise hors tension, le redémarrage, la suspension et l'hibernation du système, y compris lorsque d'autres utilisateurs peuvent encore être connectés.
• Les actions de udisks (org.freedesktop.udisks2.policy) régies par polkit comprennent le montage de systèmes de fichiers et le déverrouillage de périphériques chiffrés.
• Les actions de NetworkManager (org.freedesktop.NetworkManager.policy) régies par polkit incluent l'activation et la désactivation du réseau, du wifi ou du haut débit mobile.

Chaque action est définie dans une balise <action> dans un fichier .policy. Le fichier org.gnome.gparted.policy contient une seule action et ressemble à ceci :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//FR"
 "http://www.freedesktop.org/software/polkit/policyconfig-1.dtd">
<policyconfig>

  <action id="org.gnome.gparted">
    <message>Une authentification est nécessaire pour exécuter l'éditeur de partition GParted</message>.
    <icon_name>gparted</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/bin/gparted</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
  </action>

</policyconfig>

L'attribut id est la commande réelle envoyée à D-Bus, la balise message est l'explication à l'utilisateur lorsque l'authentification est requise et le icon_name est en quelque sorte évident.

La balise defaults est l'endroit où se trouvent les permissions ou leur absence. Elle contient trois paramètres : allow_any, allow_inactive, et allow_active. Les sessions inactives sont généralement des sessions à distance (SSH, VNC, etc.) alors que les sessions actives sont connectées directement à la machine sur un TTY ou un écran X. allow_any est le paramètre qui englobe les deux scénarios.

Pour chacun de ces paramètres, les options suivantes sont disponibles :

• no : L'utilisateur n'est pas autorisé à effectuer l'action. Il n'y a donc pas besoin d'authentification.
• oui : L'utilisateur est autorisé à effectuer l'action sans aucune authentification.
• auth_self : L'authentification est nécessaire mais l'utilisateur ne doit pas nécessairement être un utilisateur administratif.
• auth_admin : L'authentification en tant qu'utilisateur administratif est requise.
• auth_self_keep : Identique à auth_self mais, comme sudo, l'autorisation dure quelques minutes.
• auth_admin_keep : Identique à auth_admin mais, comme sudo, l'autorisation dure quelques minutes.

Ce sont les paramètres par défaut et, à moins qu'ils ne soient remplacés dans une configuration ultérieure, ils seront valables pour tous les utilisateurs.

Comme on peut le consulter dans l'action GParted, les utilisateurs doivent s'authentifier en tant qu'administrateurs pour pouvoir utiliser GParted, que la session soit active ou inactive.

Règles d'autorisation

Les règles d'autorisation qui supplantent les paramètres par défaut sont disposées dans un ensemble de répertoires comme décrit ci-dessus. Pour tout ce qui concerne la configuration personnelle d'un seul système, seul /etc/polkit-1/rules.d doit être utilisé.

La méthode addRule() est utilisée pour ajouter une fonction qui peut être appelée chaque fois qu'un contrôle d'autorisation pour l'action et le sujet est effectué. Les fonctions sont appelées dans l'ordre où elles ont été ajoutées jusqu'à ce qu'une des fonctions renvoie une valeur. Ainsi, pour ajouter une règle d'autorisation qui est traitée avant les autres règles, mettez-la dans un fichier dans /etc/polkit-1/rules.d avec un nom qui trie avant les autres fichiers de règles, par exemple 00-early-checks.rules.

La disposition des fichiers .rules est assez explicite :

/* Autoriser les utilisateurs du groupe admin à exécuter GParted sans authentification */
polkit.addRule(function(action, subject) {
    si (action.id == "org.gnome.gparted" &&
        subject.isInGroup("admin")) {
        return polkit.Result.YES ;
    }
}) ;

Dans la fonction, nous vérifions l'ID de l'action spécifiée (org.gnome.gparted) et le groupe de l'utilisateur (admin), puis nous retournons la valeur "yes".

Identités d'administrateur

La méthode addAdminRule() est utilisée pour ajouter une fonction qui peut être appelée lorsque l'authentification de l'administrateur est requise. La fonction est utilisée pour spécifier quelles identités peuvent être utilisées pour l'authentification de l'administrateur pour le contrôle des autorisations identifié par l'action et le sujet. Les fonctions ajoutées sont appelées dans l'ordre où elles ont été ajoutées jusqu'à ce que l'une des fonctions renvoie une valeur.

La configuration par défaut des identités de l'administrateur est contenue dans le fichier 50-default.rules. Toute modification de cette configuration doit être effectuée en copiant le fichier dans, par exemple, 40-default.rules et en modifiant ce fichier.

/etc/polkit-1/rules.d/50-default.rules

polkit.addAdminRule(function(action, subject) {
    return ["unix-group:wheel"] ;
});

Note: Votre utilisateur doit être listé comme membre du groupe dans /etc/group. Le fait de l'avoir simplement comme groupe principal ne fonctionne pas avec polkit. Consultez le rapport 131 de polkit.

La seule partie à modifier (une fois copiée) est le tableau de retour de la fonction : en tant que qui un utilisateur doit-il s'authentifier lorsqu'on lui demande de s'authentifier en tant qu'utilisateur administratif ? Si elle est elle-même membre du groupe désigné comme admins, il lui suffit d'entrer son propre mot de passe. Si un autre utilisateur, par exemple root, est la seule identité d'administrateur, il devra entrer le mot de passe de root. Le format de l'identification de l'utilisateur est le même que celui utilisé pour désigner les autorités.

La valeur par défaut de l'Arch est de faire de tous les membres du groupe wheel des administrateurs. Une règle comme celle ci-dessous fera que polkit demandera le mot de passe root au lieu du mot de passe de l'utilisateur pour l'authentification de l'administrateur.

/etc/polkit-1/rules.d/49-rootpw_global.rules

].
/* Toujours authentifier les administrateurs en demandant le mot de passe root
 * Mot de passe root, similaire à l'option rootpw de sudo.
 */
polkit.addAdminRule(function(action, subject) {
    return ["unix-user:root"] ;
}) ;

Exemples

Débogage/journalisation

La règle suivante enregistre des informations détaillées sur tout accès demandé.

/etc/polkit-1/rules.d/00-log-access.rules

polkit.addRule(function(action, subject) {
    polkit.log("action=" + action) ;
    polkit.log("subject=" + subject) ;
});

Désactiver la suspension et la mise en veille prolongée

La règle suivante désactive la suspension et la mise en veille prolongée pour tous les utilisateurs.

/etc/polkit-1/rules.d/10-disable-suspend.rules

polkit.addRule(function(action, subject) {
    si (action.id == "org.freedesktop.login1.suspend" ||
        action.id == "org.freedesktop.login1.suspend-multiple-sessions" ||
        action.id == "org.freedesktop.login1.hibernate" ||
        action.id == "org.freedesktop.login1.hibernate-multiple-sessions")
    {
        return polkit.Result.NO ;
    }
});

Contournement de l'invite de mot de passe

Pour obtenir quelque chose de similaire à l'option sudo NOPASSWD et obtenir une autorisation uniquement basée sur l'identité user/group, vous pouvez créer des règles personnalisées dans /etc/polkit-1/rules.d/. Cela vous permet de remplacer l'authentification par mot de passe soit pour des actions spécifiques, soit globalement. Consultez [1] pour un exemple de règle.

Globalement

Créez le fichier suivant en tant que root :

/etc/polkit-1/rules.d/49-nopasswd_global.rules

].
/* Autoriser les membres du groupe wheel à exécuter toute action
 * sans authentification par mot de passe, similaire à "sudo NOPASSWD :"
 */
polkit.addRule(function(action, subject) {
    if (subject.isInGroup("wheel")) {
        return polkit.Result.YES ;
    }
}) ;

Remplacez wheel par tout groupe de votre choix.

Il en résultera une authentification automatique pour 'toute action nécessitant des droits d'administrateur via Polkit. Il faut donc faire attention au groupe auquel vous choisissez de donner ces droits.

Il existe également AUTH_ADMIN_KEEP qui permet de conserver l'autorisation pendant 5 minutes. Cependant, l'autorisation est par processus, donc si un nouveau processus demande une autorisation dans les 5 minutes, le nouveau processus demandera à nouveau le mot de passe de toute façon.

Pour des actions spécifiques

Créez le fichier suivant en tant que root :

/etc/polkit-1/rules.d/49-nopasswd_limited.rules

/* Permet aux membres du groupe wheel d'exécuter les actions définies 
 * sans authentification par mot de passe, similaire à "sudo NOPASSWD :"
 */
polkit.addRule(function(action, subject) {
    si ((action.id == "org.gnome.gparted" ||
	 action.id == "org.libvirt.unix.manage") &&
        subject.isInGroup("wheel"))
    {
        return polkit.Result.YES ;
    }
}) ;

Les action.id sélectionnés ici ne sont que des exemples (de travail) pour GParted et Libvirt, mais vous pouvez les remplacer par n'importe quels autres de votre choix tant qu'ils existent (personnalisés ou fournis par un paquet), et vous pouvez également définir n'importe quel groupe à la place de wheel.

L'opérateur || est utilisé pour délimiter les actions (OU logique), et && signifie ET logique et doit être conservé comme dernier opérateur.

Udisks

Les gestionnaires de fichiers peuvent demander un mot de passe lorsqu'ils essaient de monter un périphérique de stockage, ou produire une erreur de type Non autorisé ou similaire. Consultez Udisks#Configuration pour plus de détails.

Autoriser la gestion d'unités systemd individuelles par des utilisateurs réguliers

En vérifiant certaines valeurs passées à la vérification de la politique de polkit, vous pouvez donner à des utilisateurs ou groupes spécifiques la possibilité de gérer des unités spécifiques. Par exemple, vous pourriez vouloir que les utilisateurs réguliers puissent démarrer et arrêter wpa_supplicant :

/etc/polkit-1/rules.d/10-wifimanagement.rules

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units") {
        if (action.lookup("unit") == "wpa_supplicant.service") {
            var verb = action.lookup("verb");
            if (verb == "start" || verb == "stop" || verb == "restart") {
                return polkit.Result.YES;
            }
        }
    }
});

Voir aussi

• Manuel de Polkit
• Autorisation avec PolKit (guide de sécurité d'openSUSE Leap)