Fonctionnement interne

Authentification X
Le programme que vous exécutez va fonctionner sous l'identité du superutilisateur et n'aura généralement pas accès à votre affichage Xwindow. contourne ce problème en ajoutant un cookie d'authentification pour votre affichage dans un fichier temporaire nommé .Xauthority. Après la fin de la commande, ce fichier sera supprimé.
Si vous ne voulez pas utiliser de cookies X, vous devrez vous débrouiller par vos propres moyens. le détectera et n'ajoutera pas de cookie, mais il vous faudra vous assurer que le superutilisateur est autorisé à accéder à votre affichage Xwindow.

Interface avec su
utilise la commande su du système pour acquérir ses privilèges. Dans cette section, j'explique en détail ce fonctionnement.
Du fait que certaines implantations de su (comme celle de ) ne veulent pas lire le mot de passe depuis stdin, crée une paire pty / tty et exécute su avec ses entrées-sorties standards connectées à tty.
Pour exécuter la commande choisie par l'utilisateur, au lieu d'un shell interactif, utilise l'argument -c avec su. Cet argument est compris par tous les shells que je connais, donc le programme devrait être portable. su passe cet argument -c au shell de l'utilisateur, et le shell exécute le programme. Exemple de commande su root -c le_programme.
Plutôt que d'exécuter directement la commande avec su, exécute un petit morceau de programme nommé kdesu_stub. Exécuté pour le compte de l'utilisateur cible, il demande quelques informations à à travers le canal pty / tty (qui correspond à son stdin et à son stdout) et exécute le programme de l'utilisateur. L'information qui est transmise comprend : l'affichage X, le cookie d'authentification X (le cas échéant), le PATH et la commande à lancer. La raison pour laquelle un petit programme intermédiaire est utilisé, c'est que le cookie X est une information privée et que, pour cette raison, il ne peut pas être passé sur la ligne de commande.

Vérification du mot de passe
vérifie le mot de passe que vous donnez et envoie un message d'erreur s'il n'est pas correct. La vérification passe par un programme de test : /bin/true. Si le test réussit, le mot de passe est considéré comme étant correct.

Conservation du mot de passe
Pour votre confort, comprend une fonction de conservation du mot de passe. Si vous vous intéressez aux questions de sécurité, vous devriez lire ce paragraphe.
Le fait de permettre à de se souvenir des mots de passe ouvre une (petite) brèche de sécurité dans votre système. Évidemment, n'autorise personne d'autre que vous-même (votre user id) à utiliser ces mots de passe, mais, si on n'y prend pas garde, ceci descend le niveau de sécurité du superutilisateur à celui d'un utilisateur normal (vous). Un hacker qui prendrait possession de votre compte pourrait ainsi obtenir l'accès superutilisateur. essaye d'éviter cela. La technique qu'il utilise pour cela est, au moins de mon point de vue, raisonnablement sûre et elle est exposée ci-dessous.
utilise un daemon, nommé kdesud. Ce daemon attend des commandes dans un socket placé dans /tmp. Le mode de ce socket est 0600, ainsi seul votre utilisateur peut s'y connecter. Si la conservation des mots de passe est activée, exécute les commandes par l'intermédiaire de ce daemon. Il écrit la commande et le mot de passe superutilisateur dans ce socket, puis le daemon exécute la commande su comme décrit précédemment. Ensuite, la commande et le mot de passe ne sont pas détruits. Au lieu de cela, ils sont conservés pour une durée déterminée. Il s'agit de la durée spécifiée dans le module de configuration. Si une autre requête pour la même commande intervient pendant cette période, le client ne vous demandera pas de fournir de nouveau le mot de passe. Pour empêcher les hackers qui prendraient le contrôle de votre compte de voler les mots de passe au daemon (par exemple en lui attachant un débogueur), le daemon est installé set-group-id nogroup. Ceci devrait interdire à tous les utilisateurs normaux (y compris vous) d'obtenir les mots de passe dans le processus kdesud. Par ailleurs, le daemon fixe la variable d'environnement DISPLAY à la valeur qu'elle avait quand il a été lancé. Ainsi, la seule chose que puisse faire un hacker est d'exécuter une application sur votre écran.
Un point faible dans ce schéma est que le programme que vous exécutez n'a peut être pas été écrit avec un grand souci de sécurité (comme c'est le cas pour les programmes setuid root). Ceci signifie que ce programme pourrait avoir des débordements de tampons (« buffer overruns ») ou d'autres faiblesses qu'un hacker pourrait utiliser.
La conservation des mots de passe est donc le fruit d'un compromis entre confort et sécurité. Je vous incite à y réfléchir et à décider par vous-même si vous souhaitez vous en servir ou pas.