les scripts d'AlternC affichent le password root partout

[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.

[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.

[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 ...

[OlivierH]

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

[fil@…]

Oui à mon avis il faut le fermer

[anarcat]

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

[joe]

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

[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 ?

[anonymous]

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

[joe]

Début de solution entrepris dans [998].

[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... :)

[anarcat]

style

[anarcat]

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).

[anarcat]

grep -r MYSQL_PASS the trunk for places to fix.

[anarcat]

patch à réviser

[anarcat]

second brain dump

[anarcat]

third brain dump, ~500 lines unified

[anarcat]

more brain dumping

[anarcat]

avec cette patch, je peux faire des upgrades

[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, ...)

[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)

[anarcat]

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