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

Posté par  .
Étiquettes : aucune
0
23
mar.
2005
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.
  • # Gruik

    Posté par  (site web personnel) . É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...
  • # Commentaire supprimé

    Posté par  . Évalué à 2.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Un daemon intermédiaire

      Posté par  . É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
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 3.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Un daemon intermédiaire

          Posté par  . É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  . É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?
  • # Gestion des utilisateurs....

    Posté par  . É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! :)
    • [^] # Re: Gestion des utilisateurs....

      Posté par  (site web personnel) . É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.
    • [^] # Re: Gestion des utilisateurs....

      Posté par  . É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  . É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.

Suivre le flux des commentaires

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