Ticket #318 (assigned defect)

Opened 4 years ago

Last modified 1 month ago

les scripts d'AlternC affichent le password root partout

Reported by: anarcat Assigned to: anarcat (accepted)
Priority: block Milestone: alternc-0.9.9
Component: Shell-scripts et binaires Version: alternc-0.9.4
Severity: major Keywords:
Cc:

Description (Last modified by anarcat)

Plusieurs scripts d'AlternC ont des appels comme: 

MYSQL_SELECT="/usr/bin/mysql -u${MYSQL_USER} -p${MYSQL_PASS} -Bs ${MYSQL_DATABASE} -e "

Ceci fait que le mot de passe MYSQL_PASS est lisible avec un simple appel 'ps', ce qui défait toute l'idée d'avoir des utilisateurs différents pour les usagers d'alternc.

Attachments

fix_318.diff (12.7 kB) - added by anarcat on 04/12/08 23:41:48.
patch à réviser
fix_318-2.diff (12.2 kB) - added by anarcat on 04/13/08 02:22:28.
second brain dump
fix_318-3.diff (18.9 kB) - added by anarcat on 04/13/08 02:23:35.
third brain dump, ~500 lines unified
fix_318-5.diff (20.9 kB) - added by anarcat on 04/13/08 04:08:05.
more brain dumping
fix_318-6.diff (21.6 kB) - added by anarcat on 04/13/08 05:37:55.
avec cette patch, je peux faire des upgrades

Change History

11/11/04 03:25:41 changed by anarcat

Ce qu'il faudrait, c'est avoir MYSQL_USER et MYSQL_PASS dans un fichier .my.cnf dans le compte root. Ceci éviterait d'avoir le mot de passe root partout.

11/11/04 07:38:50 changed by benjamin

console 1 : brassens:~# mysql -usysusr -ptototititata system

console 2 : brassens:~# ps fauxw => root 3311 0.1 0.2 6032 2168 ttyp0 S+ 06:37 0:00 | \_ mysql -usysusr -px xxxxxx system

ok, mysql modifie sa propre ligne de commande, le mot de passe est non visible ;)

De plus, le premier qui arrive à faire un "ps" depuis un compte AlternC, qu'il m'appelle ...

02/17/06 20:42:26 changed by OlivierH

Ne pourrait on pas, donc, fermer cette "fausse alerte" ?

03/15/06 15:39:30 changed by fil@rezo.net

  • type set to defect.

Oui à mon avis il faut le fermer

04/01/06 22:36:10 changed by anarcat

  • priority changed from immediate to normal.
  • version set to 0.9.4.
  • severity changed from block to major.
  • milestone set to 0.9.5.

je persiste à croire que alternc pourrait utiliser /etc/mysql/debian.cnf ou un autre fichier de conf similaire.

04/02/06 07:25:30 changed by joe

anarcat, tout à fait d'accord, un "race-condition", peu-importe sa probabilité est un défaut de sécurité.

04/05/06 01:28:12 changed by nahuel 

<Vanzetti> 1) utiliser /etc/mysql/debian.cnf
<Vanzetti> mais ce serait utiliser la conf de debian etnon celle d'alternc
<Vanzetti> mais on est sur qu'elle fonctionnera tout le temps
<Vanzetti> 2) creer un fichier de conf /etc/alternc/mysql.conf
<Vanzetti> que l'on utiliserait
<Vanzetti> et qui n'appartiendrait pas à debian
<Vanzetti> et on pourrait meme y transferer toute la conf de mysql
<Vanzetti> d'alternc
<Vanzetti> zen pensez quoi ?

04/07/06 17:38:04 changed by anonymous

J'irais pour l'approche #2, ca semble plus conforme avec la politique de debian sur les fichiers de config.

04/07/06 17:39:13 changed by anonymous

  • status changed from new to assigned.

04/07/06 17:39:55 changed by joe

  • status changed from assigned to new.
  • owner changed from anonymous to joe.

04/07/06 23:40:59 changed by joe

  • status changed from new to assigned.

Début de solution entrepris dans [998].

04/08/06 00:23:53 changed by anarcat

alors "biting the bullet"? je ne l'espérait pas vraiment. :) il faudrait faire attention de ne pas dupliquer le mot de passe dans local.php pour rien. Il faudrait, tant qu'à dupliquer l'info, faire carrément un nouveau user pour le bureau. Il faudrait réviser quels sont les privilèges nécessaires dans local.php et s'ils sont différents de ceux de local.sh, faire un user séparer. Tant qu'à foutre le bordel... :)

04/08/06 00:28:02 changed by anarcat

  • description changed.

style

04/25/06 05:34:23 changed by anarcat

  • milestone changed from 0.9.5 to 1.0.

commit was reverted in [1001] because the solution wasn't complete. postponing to 1.0 since this is not critical and we're out of time (again).

04/12/08 01:31:59 changed by anarcat

  • milestone changed from alternc-1.0 to alternc-0.9.8.

04/12/08 04:11:52 changed by anarcat

  • status changed from assigned to new.
  • owner changed from joe to anarcat.

grep -r MYSQL_PASS the trunk for places to fix.

04/12/08 04:12:15 changed by anarcat

  • priority changed from normal to block.
  • status changed from new to assigned.

04/12/08 23:41:48 changed by anarcat

  • attachment fix_318.diff added.

patch à réviser

04/13/08 02:22:28 changed by anarcat

  • attachment fix_318-2.diff added.

second brain dump

04/13/08 02:23:35 changed by anarcat

  • attachment fix_318-3.diff added.

third brain dump, ~500 lines unified

04/13/08 04:08:05 changed by anarcat

  • attachment fix_318-5.diff added.

more brain dumping

04/13/08 05:37:55 changed by anarcat

  • attachment fix_318-6.diff added.

avec cette patch, je peux faire des upgrades

04/13/08 06:15:52 changed by anarcat

note that the way the current patch deals with GRANTs will allow us to actually *REMOVE* the old grants when, for example, the root username changes (#601).

it also paves the way towards various my.cnf for alternc for the different services, in isolation... (#364, ...)

04/13/08 06:35:20 changed by anarcat

(In [2117]) Major redesign of the MySQL backend interface to fix a security issue. See: #318.

As of now, the MySQL configuration used everywhere by AlternC is not stored in the main configuration file (/etc/alternc/local.sh) but in a MySQL configuration file in /etc/alternc/my.cnf, which enables us to call mysql without exposing the password on the commandline.

The changes here are quite invasive but will allow us to factor out the MySQL configuration better. See #364.

This includes a partial rewrite of the mysql.sh logic, which is now ran from the postinst script (and not alternc.install) which will allow us to actually change the MySQL root user properly. See #601.

This commit was tested like this:

  • clean install on etch (working)
  • upgrade from a clean 0.9.7 (working)

04/13/08 07:15:06 changed by anarcat

j'attend de faire l'upgrade de notre serveur de prod avec ces fixes avant de fermer le bug.