Journal demande graphique du mot de passe root

Posté par  .
Étiquettes : aucune
0
6
sept.
2003
salut mon vieux journal

j'ai vu, il n'y a pas très longtemps, sur une redhat 8, une petite boite de dialogue qui te demande le mot de passe root lorsque tu veux lancer certaines appli en tant qu'un utilisateur lambda, ils y a même un petit framework sympa (un petit single sign-on temporaire est activé, tu n'as pas besoin de retaper le mot de passe pour d'autres applis du style, et ce pendant une poignée de minutes), bref c'est trop hype comme truc

comment ce système fonctionne-t-il ?
est-ce que redhat a modifié les applis en question, ou bien détecte magiquement que l'appli va en avoir besoin ?

j'ai essayé un strace, mais comme je suis un hacker du dimanche j'ai rien compris

merci :)
  • # Re: demande graphique du mot de passe root

    Posté par  . Évalué à 2.

    C'est plus simple que tu ne le penses. C'est juste un programme tiers qui le gère. Sur la console ca équivaut à faire :
    $ su -c <ta commande nécessitant les privilèges de root>

    su se contente de te logger en tant que l'utilisateur spécifié (root par défaut), puis de lancer la commande indiquée.

    Des programmes graphiques font la même chose, par exemple xsu, gnomesu et beaucoup d'autres.
    • [^] # Re: demande graphique du mot de passe root

      Posté par  . Évalué à 2.

      C'est plus complexe qu'un simple su -c ... notamment pour le système de persistance de l'authentification ...

      Ca utilise en fait sudo ... par contre pour les interfaces graphiques je n'ai pas vraiment recherché.
      • [^] # Re: demande graphique du mot de passe root

        Posté par  (site web personnel) . Évalué à 10.

        hum, non ça n'utilise pas sudo du tout mais des modules PAM

        le système fonctionne ainsi :

        - tu as une appli qui a besoin des droits root pour fonctionner (typiquement un redhat-config-machin). L'appli se trouve dans /usr/sbin ;

        - dans /usr/bin il y a un lien symbolique portant le même nom (redhat-config-machin) vers le programme /usr/bin/consolehelper ;

        - quand un utilsateur non-root exécute redhat-config-machin, comme il n'a pas /usr/sbin dans son PATH, c'est consolehelper qui est appelé ;

        - consolehelper va authentifier l'utilisateur via PAM en utilisant le fichier /etc/pam.d/redhat-config-machin qui indique quels sont les modules PAM à utiliser. Il va ensuite exécuter le programme voulu avec l'utilisateur voulu, tels que définis dans le fichier /etc/security/console.apps/redhat-config-machin . En fait consolehelper ne fait pas grand chose car il n'est pas suid root, c'est /usr/sbin/userhelper qui fait tout ça.

        - il y a une version GTK de consolehelper qui fait qu'on obtient une jolie fenêtre demandant le mot de passe ;

        - le bazar utilise souvent le module pam_timestamp qui évite d'avoir à retapper le mot de passe s'il a été entré il y a peu. Une applet du panel GNOME (pam-panel-icon) indique quand c'est le cas.
        • [^] # Re: demande graphique du mot de passe root

          Posté par  . Évalué à 1.

          [++] :)

          donc on peut faire facilement ce genre de trucs soi-meme

          dernier truc flou... comment fait consolehelper pour récupérer le nom du programme voulu ? Lorsqu'on lance un programme via un lien symbolique, ce dernier peut récupérer le nom du lien via argv[] ?
  • # Re: demande graphique du mot de passe root

    Posté par  . Évalué à 2.

    C'est gksu non ?
    En tout cas, en fonction de la description, cela me fait penser à cela. J'utilise ce petit programme pour lancer certaines applications en root (typiquement, ma connection internet, mon firewall, etc).
    Pour le fonctionnement, le mieux est encore les sources (j'y avais jeté un coup d'oeil à l'époque, mais bon, j'ai en bonne partie oublié, et pis voilà !).
  • # Re: demande graphique du mot de passe root

    Posté par  (site web personnel) . Évalué à 1.

    kdesu -c <la commande demandé>
    autre question?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.