KDE su utilise le "su" du système pour acquérir ses privilèges. Dans ce paragraphe, j'explique en détail ce fonctionnement.
Because some su implementations (i.e. the one from Redhat) don't want to read the password from stdin, KDE su creates a pty/tty pair and executes "su" with it's standard filedescriptors connected to the tty.
Parceque certaines implantations (comme celle de RedHat) ne veulent pas lire le mot de passe depuis stdin, KDE su 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, KDE su 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 the_program".
Plutôt que d'exécuter directement la commande avec su, KDE su exécute un petit morceau de programme nommé kdesu_stub. Exécuté pour le compte de l'utilisateur cible, il demande quelques informations à KDE su à 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.