Retourner aux forums || Retourner au forum Programmation.perl

Programmation.perl : Cacher un mot de passe dans le fichier

Posté par redlums35 () le 23 mars 2005
0
Bonjour,

J'ai créer un programmen Perl-GTK qui utilise des fonctions mysql. Ce programme va changer des valeur d'une table Mysql selon le bouton cliqué dans le programme. Ca marche bien.
Par contre chaque utilisteur doit pouvoir l'executer, le problème c'est que executer signifie aussi lire et donc ils peuvent voir le mot de passe de ma base mysql fourni dans la fonction :
DBI->connect("DBI:mysql:mabase:localhost","login","pass")

Merci pour vos idées afin d'empecher de lire le mot de passe mais que tout le monde puisse executer le programme.

> Lire le message (13 commentaires, moyenne: 2,1).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Gruik

Posté par Khâpin (Jabber id, page perso, ) le 23/03/2005 à 08:53. (lien). Évalué à 1.

Je vois bien une solution, mais c'est plutôt gruik, et il faut que tu sois sûr de ton programme: tu le mets suid root, et il lit le mot de passe dans un fichier que seul root peut lire...

  • [^]Re: Gruik

    Posté par alenvers () le 23/03/2005 à 08:56. (lien). Évalué à 5.

    Autant le mettre suid d'un autre utilisateur que le root alors ;-)

Un daemon intermédiaire

Posté par alenvers () le 23/03/2005 à 08:55. (lien). Évalué à 2.

Il n'y a pas moyen !

Il faut faire un daemon (un proxy) qui fait la requete pour l'applic perl-gtk.



Applic -> deamon -> DB
^^^
L'ulisateur s'authentifie au démon (login,pass p^ropre à l'utilisateur)

  • [^]Re: Un daemon intermédiaire

    Posté par redlums35 () le 23/03/2005 à 09:36. (lien). Évalué à 1.

    Y' pas de solution alors ?
    comment font les programmes qui se connectent a des serveurs de BDD (en ecriture) sans que l'utilisateur puisse voir le mot de passe ?
    Peut etre que cela marcherait en gtk pure et compiler avec gcc (apres compilation le programme est ilisible)
    Mais comment integrer des acces mysql dans un programme en pure gtk pour le compiler avec gcc ?
    Avec perl-gtk aucune compilation n'est demandé, on l'execute directement.

    Merci pour votre aide

    • [^]Re: Un daemon intermédiaire

      Posté par alenvers () le 23/03/2005 à 10:09. (lien). Évalué à 3.

      >(apres compilation le programme est ilisible)

      Non, le mot de passe apparaitra toujours... C'est juste un peu plus compliqué pour le retrouver.

      >comment font les programmes qui se connectent a des serveurs de
      >BDD (en ecriture) sans que l'utilisateur puisse voir le mot de passe ?

      Ils utilisent un proxy qui fait la requete pour eux (dont ils n'ont pas le code).

      • [^]Re: Un daemon intermédiaire

        Posté par redlums35 () le 23/03/2005 à 10:31. (lien). Évalué à 1.

        Merci pour ton idée,

        Peut-tu me donner quelques pistes (adresses) pour créer un demon lancé au démarrage et apres lui passer des parametres avec un aplli ?

        Merci

        • [^]Re: Un daemon intermédiaire

          Posté par alenvers () le 23/03/2005 à 11:59. (lien). Évalué à 2.

          J'avais écrit un tel démon (en c, client en perl) pour la tribune :
          http://alenvers.dyndns.org/dawoofd/(...)

          Amha, il ne doit plus très bien fonctionner avec le format xml de linuxfr (le parser est tres gruiiik) mais cela peut te donner des idées...

  • [^]Re: Un daemon intermédiaire

    Posté par Philippe Piette () le 23/03/2005 à 11:39. (lien). Évalué à 1.

    Pourquoi utiliser un mot de passe alors?
    Il suffit, me semble-t-il de créer un utilisateur qui a le droit d'écrire dans ta table, utilisateur qui ne nécessite pas de mot de passe.
    Non?

    • [^]Re: Un daemon intermédiaire

      Posté par alenvers () le 23/03/2005 à 11:55. (lien). Évalué à 2.

      Ce que l'utilisateur à la possibilité doit rester dans le cadre de ce qu'offre l'application. Cad ne pas permettre de faire n'importe quoi sur la base de donnée.

Gestion des utilisateurs....

Posté par Potato () le 23/03/2005 à 12:23. (lien). Évalué à 4.

Tu ne pourrais pas créer des utilisateurs pour ta base de donnée?
Comme ça chacun aurait son mot de passe....
Enfin moi je dis ça mais je dis rien! :)

--
Potato
  • [^]Re: Gestion des utilisateurs....

    Posté par -=[ Benoit Plessis ]=- (page perso, ) le 23/03/2005 à 13:15. (lien). Évalué à 2.

    Et bein moi je te plusse.

    J'en ai marre des demon et autres proxy d'authentification qui sont plus bugués que les systèmes d'authentification qu'ils protegent.
    MySQL (etPostgreSQL) possede une gestion des utilisateurs et de leurs droits.
    A vous de les gérer correctement.

    --
    Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libre)
  • [^]Re: Gestion des utilisateurs....

    Posté par Matthieu MARC () le 23/03/2005 à 15:21. (lien). Évalué à 2.

    heu, et avec des certificats x509, ça ne pourrait pas être une solution (je dis être car elle n'existe peut-être pas)

    Ne peuvent se connecter au serveur MySQL que ceux qui ont des certificats valides....

    a voir

  • [^]Re: Gestion des utilisateurs....

    Posté par platinum () le 23/03/2005 à 21:35. (lien). Évalué à 1.

    Comme l'a dit alenvers (https://linuxfr.org/comments/550927.html#550927(...) ) la problématique n'est pas forcément la même.

    Par exemple les utilisateurs finaux sont gérés par des droits dits applicatifs et les applications par des droits systèmes.

    Dans le cas de la base de donnée, il y a souvent des applications provenant de différents fournisseurs. Dans ce cas, il y a donc ce niveau intermédiaire d'authentification qui identifie quelle application a le droit de se connecter avec quels privilèges. Et chaque application s'occupe de gérer ses propres utilisateurs.

    On peut évidemment faire coïncider les deux ou même les trois identifications. Plus une application est verticalisée plus ce cas est fréquent.

Revenir en haut de page || Retourner aux forums || Retourner au forum Programmation.perl