20 juin 2011

Installation d'un domU Xen Enterprise Linux sur un dom0 NetBSD

Lire la suite...

Ces derniers temps je m'amuse à faire des installations par le réseau d'un peu tout et n'importe quoi. J'utilise principalement l'outil de virtualisation Oracle VirtualBox, mais il m'arrive aussi de faire joujou avec Xen. Avec un hôte (dom0) CentOS 5 (et sans doute toutes les distribution de type "Enterprise Linux" telles que Red Hat Enterprise Linux ou Scientific Linux), il est très facile de créer d'autres machines virtuelles (domU) Xen de même type grâce à la commande "virt-install". Avec un dom0 NetBSD cependant, point de commande de ce type. Voyons donc comment faire.

Sur un système Enterprise Linux 5, il est possible de trouver une image de noyau d'installation (et l'initrd approprié) spécifique à Xen, comme par exemple sur ce miroir pour CentOS 5 64 bits.

Ce qui me paraît étrange, c'est avec Enterprise Linux 6, tout du moins avec Scientific Linux. Le noyau 2.6.32 dispose à priori des pv-ops, mais SL6 dispose d'un noyau et d'un initrd Xen. Peut-être est-ce par soucis de compatibilité de chemins, car les fichiers font la même taille que dans le répertoire pxeboot. D'ailleurs, lors de ma synchronisation rsync avec le miroir officiel Scientific Linux, le répertoire xen n'apparaît pas. Et je n'en ai pas eu besoin :)

Une fois nos images de noyau et d'initrd en main, il nous reste à créer notre fichier de configuration de domU, mon exemple prend comme exemple de disque dur un fichier et une connexion réseau par bridge :

name = "centosexample"
uuid = ""
maxmem = 512
memory = 512
kernel  = "/srv/www/pub/CentOS/5/os/x86_64/images/xen/vmlinuz"
ramdisk = "/srv/www/pub/CentOS/5/os/x86_64/images/xen/initrd.img"
extra = "vnc"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [  ]
disk = [ "file:/srv/xen/images/disk/centosexample.img,xvda,w" ]
vif = [ "mac=00:16:3a:e2:12:34,bridge=bridge0" ]

Il est possible de faire l'installation en mode texte en supprimant la ligne "extra", et d'ajouter l'url d'un fichier kickstart dans la directive extra, qui devient donc :

extra = "text ks=http://monserveur/pub/cfg/centos5_x86_64.cfg"

La commande "xm create -c centosexample" vous permet de lancer votre domU et de débuter l'installation. Une fois celle-ci faite et votre domU de nouveau éteint, il suffit de commenter les lignes "kernel" et "ramdisk" et de décommenter la ligne "bootloader". Vous pouvez alors démarrer votre domU sans que le noyau de celui-ci soit sur le disque dur du dom0 :)

Lors de mes tests, je me suis limité au partitionnement par défaut (qui utilise LVM), à un détail près : avec Scientific Linux 6, j'ai imposé ext3 à l'installeur. Une fois l'installation terminée, éteindre son domU (proprement de préférence) et modifier la configuration qui devient :

name = "centosexample"
uuid = ""
maxmem = 512
memory = 512
bootloader = "/usr/pkg/bin/pygrub"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [  ]
disk = [ "file:/srv/xen/images/disk/centosexample.img,xvda,w" ]
vif = [ "mac=00:16:3a:e2:12:34,bridge=bridge0" ]

J'ai donc remplacé le noyau et l'initrd d'installation par pygrub, qui me permet de démarrer mon domU sur le noyau et l'initrd installés. De plus, les mises à jour ne nécessitent pas de copier de nouveau le noyau et l'initrd sur le dom0.

Pour finir, si vous souhaitez installer un dom0 NetBSD, je ne peux que vous recommander l'excellent billet de Bsdsx !

17 janv. 2011

Vérifications de permissions - suite

Lire la suite...

Introduction : les astuces de ce billet sont extraites du document Guide to the Secure Configuration of Red Hat Enterprise Linux 5 édité par la NSA. Vous pouvez télécharger le document au format PDF dans son intégralité sur leur site. Cette introduction me permet d'être en conformité avec leur notice de Copyright.

Après les droits des répertoires et le sticky bit, amusons-nous un peu avec SUID et SGID : un fichier possédant l'attribut SUID ou SGID permet d'être lancé avec les droits de l'utilisateur ou du groupe qui a été placé, généralement root. Ainsi, le programme at, permettant de lancer une tâche à un moment donné, est accessible aux utilisateurs classiques alors que son fonctionnement nécessite des droits plus élevés. Ceci peut s'avérer risqué car si un programme SUID root possède une faille, celle-ci peut être exploitée avec les droits de root, même si l'attaquant n'a pas les droits.

Comme pour le sticky bit, commençons par vérifier notre environnement :

root@orgrimmar:~# whoami
root
root@orgrimmar:~# cat /etc/redhat-release 
CentOS release 5.5 (Final)

Recherchons maintenant tous les fichiers possédant un SUID ou un SGID :

root@orgrimmar:~# find / \( -perm -4000 -o -perm -2000 \) -type f -print
/bin/ping6
/bin/umount
/bin/ping
/bin/mount
/bin/su
/lib64/dbus-1/dbus-daemon-launch-helper
/usr/bin/wall
/usr/bin/chfn
/usr/bin/newgrp
/usr/bin/sudoedit
/usr/bin/chsh
/usr/bin/write
/usr/bin/at
/usr/bin/chage
/usr/bin/crontab
/usr/bin/ssh-agent
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/gpasswd
/usr/bin/locate
/usr/bin/screen
/usr/libexec/openssh/ssh-keysign
/usr/libexec/libvirt_proxy
/usr/libexec/utempter/utempter
/usr/kerberos/bin/ksu
/usr/sbin/userhelper
/usr/sbin/postqueue
/usr/sbin/postdrop
/usr/sbin/usernetctl
/usr/sbin/ccreds_validate
/sbin/netreport
/sbin/mount.nfs4
/sbin/umount.nfs4
/sbin/umount.nfs
/sbin/mount.nfs
/sbin/unix_chkpwd
/sbin/pam_timestamp_check
find: /proc/9859/task/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/task/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/fd/4: Aucun fichier ou répertoire de ce type
root@orgrimmar:~# 

Sur le coup, voir autant de lignes peut paraître effrayant, mais si on y regarde de plus près, on peut comprendre que 99% des fichiers indiqués aient besoin du SUID. Le seul qui m'inquiète, c'est screen. Je vais donc regarder sur une autre machine, bien différente cette fois-ci :

nils@tomb:~$ uname -sr
NetBSD 5.0.2
nils@tomb:~$ ls -hl /usr/pkg/bin/scree*
lrwxr-xr-x  1 root  wheel   12B Jul 11 11:23 /usr/pkg/bin/screen@ -> screen-4.0.3
-r-s--x--x  1 root  wheel  279K Jul 11 11:23 /usr/pkg/bin/screen-4.0.3*

On voit que screen sur ma machine NetBSD a aussi un bit SUID. C'est bon, je peux aller me coucher l'esprit tranquille :) Mais avant, revenons à notre serveur CentOS, et comme pour l'affaire du sticky bit, simulons un programme dont le SUID a été ajouté inutilement :

root@orgrimmar:~# cat > testbin
#!/bin/bash
echo -n "Je suis un programme SUID de test"
exit 0
root@orgrimmar:~# chmod -v +x testbin 
Le mode d'accès de `testbin' a été modifié à 0755 (rwxr-xr-x).
root@orgrimmar:~# ls -hl testbin 
-rwxr-xr-x 1 root root 63 déc 31 00:44 testbin*
root@orgrimmar:~# chmod -v +s testbin 
Le mode d'accès de `testbin' a été modifié à 6755 (rwsr-sr-x).
root@orgrimmar:~# ls -hl testbin 
-rwsr-sr-x 1 root root 63 déc 31 00:44 testbin*

Relançons notre recherche :

root@orgrimmar:~# find /root \( -perm -4000 -o -perm -2000 \) -type f -print
/root/testbin

Supprimons maintenant le SUID et relançons la recherche :

root@orgrimmar:~# chmod -v -s testbin 
Le mode d'accès de `testbin' a été modifié à 0755 (rwxr-xr-x).
root@orgrimmar:~# find /root \( -perm -4000 -o -perm -2000 \) -type f -print
root@orgrimmar:~# 

Et voilà, nous sommes tranquille :)

Que faire si j'ai un doute sur un programme ? Plusieurs possibilités : s'il s'agit d'un programme qui est fourni par les paquets de votre distribution, on peut toujours aller vérifier sur d'autres machines, dont l'OS ou la distribution peut différer (comme je l'ai fait avec screen); un même programme nécessitant le SUID sur 2 OS différents peut légèrement rassurer. Si le logiciel est libre (exemple : GNU screen :D), on peut aussi aller chercher dans les fichiers de création du paquet binaire, pour les RPM il suffit de chercher le SRPM du logiciel et de l'installer sur une machine de test. Ensuite, on regarde le contenu du fichier .spec qui sert à la création de ce paquet : en effet, ces fichiers contiennent la liste et les droits des fichiers et répertoires du paquet que l'on veut compiler :) Si un .spec n'indique pas que le programme est SUID, alors il est temps de s'inquiéter !

3 janv. 2011

Vérifications de permissions

Lire la suite...

Introduction : les astuces de ce billet sont extraites du document Guide to the Secure Configuration of Red Hat Enterprise Linux 5 édité par la NSA. Vous pouvez télécharger le document au format PDF dans son intégralité sur leur site. Cette introduction me permet d'être en conformité avec leur notice de Copyright.

Je vous propose de vérifier les permissions de certains de vos fichiers sur votre serveur ou poste fonctionnant sur un système Linux. Le but est de limiter les possibilités de tentatives d'intrusion en recherchant les moyens d'entrée possibles. Commençons par vérifier notre environnement :

root@orgrimmar:~# whoami
root
root@orgrimmar:~# cat /etc/redhat-release 
CentOS release 5.5 (Final)

Recherchons maintenant tous les répertoires dont les droits permettent à n'importe quel utilisateur d'écrire dedans, et dont le sticky bit n'est pas positionné :

root@orgrimmar:~# find / -type d \( -perm -0002 -a ! -perm -1000 \) -print

Si jamais votre machine possède de nombreuses partitions, et qu'elles sont du genre bien remplies, il est possible de limiter la recherche de find à une partition à la fois :

root@orgrimmar:~# find / -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:~# find /home -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:~# find /var -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print

Idéalement (et c'est le cas sur ma machine, ouf !), cette commande ne devrait occasionner aucun affichage. Maintenant, amusons-nous un peu :

root@orgrimmar:/tmp# mkdir insecure
root@orgrimmar:/tmp# chmod -v 777 insecure
Le mode d'accès de `insecure' a été modifié à 0777 (rwxrwxrwx).
root@orgrimmar:/tmp# find /tmp/ -type d \( -perm -0002 -a ! -perm -1000 \) -print
/tmp/insecure

Positionnons maintenant le sticky bit :

root@orgrimmar:/tmp# ls -hl /tmp/ | grep insecure
drwxrwxrwx 2 root root 4,0K déc 30 23:54 insecure/
root@orgrimmar:/tmp# chmod -v +t /tmp/insecure/
Le mode d'accès de `/tmp/insecure/' a été modifié à 1777 (rwxrwxrwt).
root@orgrimmar:/tmp# ls -hl /tmp/ | grep insecure
drwxrwxrwt 2 root root 4,0K déc 30 23:54 insecure/
root@orgrimmar:/tmp# find /tmp/ -type d \( -perm -0002 -a ! -perm -1000 \) -print
root@orgrimmar:/tmp# 

Qu'est-ce que le sticky bit ? Extrait de la page de manuel de chmod (man chmod) :

t (sticky-bit) conserver le code du programme sur le périphérique de swap après exécution. Il s’agit du comportement original, mais de nos jours il sert uniquement pour les répertoires. Il indique que seuls le propriétaire du répertoire, et le propriétaire d’un fichier qui s’y trouve ont le droit de supprimer ce fichier. C’est typiquement utilisé pour les répertoires comme /tmp ayant une autorisation d’écriture générale.

Vérifions cela :

root@orgrimmar:/tmp# cd /
root@orgrimmar:/# ls -hl | grep tmp
drwxrwxrwt   5 root root 4,0K déc 30 23:59 tmp/

Le sticky bit est positionné. Je suis rassuré. Néanmoins, il ne fait pas tout. Regardons donc quels répertoires sont accessibles à tous les utilisateurs, sans chercher à savoir si le sticky bit est positionné :

root@orgrimmar:/# find / -type d \( -perm -0002 \) -print
/var/tmp
/var/lib/xenstored
/dev/shm
/tmp
/tmp/insecure
/tmp/.ICE-unix

Cela fait déjà un peu plus de monde... pas très rassurant mais à part notre répertoire insecure, pas de quoi s'affoler : /var/tmp et /tmp sont des répertoires destinés aux fichiers temporaires des programmes en fonctionnement, /var/shm désigne la mémoire partagée et le xenstored sert au bon fonctionnement de l'hyperviseur Xen.

Pour finir, nous pouvons nettoyer notre petite expérience :

root@orgrimmar:/# rmdir -v /tmp/insecure/
rmdir: destruction du répertoire /tmp/insecure/
root@orgrimmar:/# ls -hal /tmp/ | grep secu

3 juin 2010

Dédé le clown et son copain le live-cd

Lire la suite...

C'est l'histoire de Dédé le clown, ou plutôt de dd le clone, qui rend bien service lorsqu'on a des sueurs froides... Mais qu'est-ce que dd ? Depuis la page de manuel, on peut lire : "convert and copy a file". C'est tellement simple qu'on se dit que ce n'est pas très puissant, mais on se met à créer des fichiers d'image disque, ou cloner des disques durs entiers, on comprend que parfois les énoncés les plus court peuvent être très complet ! La page wikipédia de dd en Français contient quelques exemples utiles, mais la page anglophone en contient encore plus !

Imaginons maintenant la situation : vous possédez deux machines, identiques. Vous installez la première et désirez installer la seconde à l'identique, il suffit de cloner le disque dur à l'aide de dd et de copier votre clone, toujours à l'aide de dd, sur la seconde machine. Une autre situation, que je ne vous souhaite pas : vous disposez de deux machines identiques toujours, mais l'OS de l'une d'entre elles se trouve endommagés (imaginez par exemple, 3/4 des fichiers de /boot disparus, idem dans /lib et à quelques autres endroits). Ajoutons à cela là contrainte que vous ne pouvez pas éteindre la machine encore en marche, et que le temps presse. Pas besoin de chercher deux heures un outil de clonage, il est installé sur votre linux adoré : dd. Récupérons un disque dur USB dont la capacité excède celle du disque local. Voici comment on clone le disque dur :

[root@machinequimarche ~]# dd bs=1M if=/dev/sda of=/media/usb/machine1.img

Je pars du principe que le disque dur s'appelle /dev/sda et que le disque USB est monté sous /media/usb/, mais cela peut différer selon la situation de chacun. On notera que l'option "bs=1M" (copier par blocs de 1 Méga-octet) rend la copie plus rapide. J'aurais bien tenté des blocs encore plus grands mais la copie s'est avérée déjà bien rapide.

Une fois la copie terminée (environ une bonne heure pour 70Go de disque, sachant qu'il y avait du raid 1 matériel sur du SCSI 10000 tours...), reste à se rendre devant la deuxième machine, de démarrer celle-ci sur un live-cd contenant lui aussi dd (n'importe quel live-cd de distriubtion Linux devrait l'avoir), et copier dans l'autre sens :

[root@machinequimarchepas ~]# dd bs=1M if=/media/usb/machine1.img of=/dev/sda

Bien sûr, on a au préalable monté le disque USB ;) Une fois la copie terminée, le disque démonté, je recommande de monter les partitions du disque local (/dev/sda pour mon cas), et d'aller modifier les noms d'hôte, les adresses IP et autres configurations particulières qu'on pourrait trouver dans /etc, sinon la mise en réseau de la machine risquerait d'être problématique. Dans le cas d'une RHEL/CentOS/Fedora, on pensera à modifier :

  • /etc/hosts
  • /etc/sysconfig/network
  • /etc/sysconfig/network-scripts/ifcf-* (selon vos configurations, plusieurs cartes réseau, bonding...)
  • /etc/sysconfig/iptables-config si vous sauvegardez ici votre firewall, sinon regardez votre script de firewall

Autre chose, surtout pour les utilisateurs des distributions sus-cités : le mode rescue n'est disponible que sur le CD1 ou DVD1, mais pas dans le boot.iso ou tout autre média de net-install. Ce mode permet de démarrer sur un système live minimaliste permettant de monter les partitions du système, de monter un disque dur usb (si vous le branchez avant de booter pour du RHEL4), et bien sûr, d'accéder à dd :)

20 juin 2008

Utilisateurs virtuels sous CentOS 5 avec base de données MySQL

convert_to_centos5_fr.sh --url howtoforge.com

Lire la suite...

Depuis quelques temps j'essayais sans succès de faire des utilisateurs virtuels avec Vsftpd, mon logiciel de serveur ftp favori, sous CentOS 5. Alors oui, la db au format Berkeley, ça marche, mais je trouve ça casse-pieds à maintenir. Et puis pour changer le mot de passe, galère. J'avais vu qu'il était possible d'utiliser MySQL comme base pour les utilisateurs et leurs mots de passe. Je me met en quête d'un how-to pour CentOS, sans succès. J'adapte donc ce how-to de Howtoforge pour CentOS.

Commençons par l'installation des paquets qui vont bien. En supposant que vous ayez, comme moi, une CentOS 5 minimaliste mais à jour, ça se passe comme ceci :

root@tristram:~ # yum -y install vsftpd mysql-server

Ensuite, soit on ajoute à ses dépôts le dépôt extras en mode testing (et là je vous encourage à faire très attention, et de n'activer que les noms des paquets nécessaires), soit on installe "à la main" le paquet pam-mysql, qui permettra à vsftpd de dialoguer avec MySQL. Le RPM est disponible sur Pbone. Moi j'ai fait :

 root@tristram:~ # wget ftp://ftp.pbone.net/mirror/centos.karan.org/el5/extras/testing/i386/RPMS/pam_mysql-0.7-0.5.rc1.el5.kb.2.i386.rpm

puis :

root@tristram:~ # rpm -ivh pam_mysql-0.7-0.5.rc1.el5.kb.2.i386.rpm

Une fois les logiciels qui vont bien installés, on peut avoir envie de gérer MySQL via phpMyAdmin, pour celà je vous renvoie à un autre billet qui en parle.

Commençons par MySQL, pour respecter l'ordre originel du howto. Une fois celui-ci installé, on configure le mot de passe de root :

root@tristram:~ # service mysqld start

MySQL indique les commandes pour changer le mot de passe de root pour MySQL, en indiquant quel est le nom d'hôte MySQL de la machine (détail très important !)

root@tristram:~ # /usr/bin/mysqladmin -u root password 'changemoi'
root@tristram:~ # /usr/bin/mysqladmin -u root -h tristram.anotherhomepage.loc password 'changemoi'

(on voit donc que la machine servant à ce howto se nomme tristram.anotherhomepage.loc) Ensuite on se connecte à MySQL :

root@tristram:~ # mysql -u root -p

On crée la base de données et son utilisateur, vsftpd et mot de passe ftpdpass :

mysql> CREATE DATABASE vsftpd;
mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP ON vsftpd.* TO 'vsftpd'@'localhost' IDENTIFIED BY 'ftpdpass';
mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP ON vsftpd.* TO 'vsftpd'@'localhost.localdomain' IDENTIFIED BY 'ftpdpass';
mysql> FLUSH PRIVILEGES;

Ensuite on créé le schéma (on est toujours dans le shell de MySQL) :

mysql> USE vsftpd;
mysql> CREATE TABLE `accounts` (
`id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`username` VARCHAR( 30 ) NOT NULL ,
`pass` VARCHAR( 50 ) NOT NULL ,
UNIQUE (
`username`
)
) ENGINE = MYISAM ;

Et on quitte MySQL :

mysql> quit;

On créée l'utilisateur virtuel pour accéder aux comptes ; sous CentOS 5, le groupe de l'utilisateur nobody est nobody, avec comme gid 99 (vu dans /etc/groups) :

root@tristram:~ # useradd --home /home/vsftpd --gid 99 -m --shell /sbin/nologin vsftpd

On note aussi que pour empêcher un compte d'avoir un shell, on met plutôt /sbin/nologin.

Passons à Vsftpd. Sauvegardons la configuration par défaut et ajoutons la nôtre :

root@tristram:~ # cp -p /etc/vsftpd/vsftpd.conf /etc/vsftpd/vsftpd.conf_orig
root@tristram:~ # cat /dev/null > /etc/vsftpd/vsftpd.conf
root@tristram:~ # vi /etc/vsftpd/vsftpd.conf

Le fichier vsftpd.conf est le suivant ( les options sont expliquées en anglais sur le site de vsftpd) :

listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
nopriv_user=vsftpd
chroot_local_user=YES
secure_chroot_dir=/var/run/vsftpd
pam_service_name=vsftpd
guest_enable=YES
guest_username=vsftpd
local_root=/home/vsftpd/$USER
user_sub_token=$USER
virtual_use_local_privs=YES
user_config_dir=/etc/vsftpd/user_conf

Une première différence avec celui de Howtoforge, je n'ai pas mis l'option rsa_cert_file=/etc/ssl/certs/vsftpd.pem, je verrai ça pour un autre billet. Une autre différence est l'endroit où je stocke les configurations personnalisées par utilisateur : comme il y a un répertoire /etc/vsftpd, j'ai créé un sous-répertoire user_conf :

root@tristram:~ # mkdir /etc/vsftpd/user_conf

Cette possibilité est bien entendue totalement optionnelle.

Il nous faut maintenant configurer pam, qui va permettre à vsftpd d'aller chercher les utilisateurs dans la base mysql plutôt que dans les utilisateurs système, stockés dans /etc/passwd et /etc/shadow. Comme avec Vsftpd, on sauvegarde l'ancien et on en crée un tout neuf :

root@tristram:~ # cp -p /etc/pam.d/vsftpd /etc/pam.d/vsftpd_orig
root@tristram:~ # cat /dev/null > /etc/pam.d/vsftpd
root@tristram:~ # vi /etc/pam.d/vsftpd

Le contenu de ce fichier est le suivant :

auth required pam_mysql.so user=vsftpd passwd=ftpdpass host=localhost db=vsftpd table=accounts usercolumn=username passwdcolumn=pass crypt=3
account required pam_mysql.so user=vsftpd passwd=ftpdpass host=localhost db=vsftpd table=accounts usercolumn=username passwdcolumn=pass crypt=3

La différence avec la version howtoforge est que j'ai changé l'algorithme de hash du mot de passe. Au lieu d'utiliser la fonction PASSWORD(), je vais utiliser MD5(). Je reviendrai sur ce qui a motivé ce choix après. Pour le moment, relançons Vsftpd :

root@tristram:~ # service vsftpd restart

Et maintenant, créons notre premier utilisateur dans MySQL :

root@tristram:~ # mysql -u root -p

Nous sommes dans le shell MySQL :

mysql> USE vsftpd;
mysql> INSERT INTO accounts (username, pass) VALUES('testuser', MD5('secret'));
mysql> quit;

Le répertoire de l'utilisateur testuser est /home/vsftpd/testuser, mais Vsftpd ne peut pas le créer automatiquement pour nous, faisons-le à la main, en prenant soin qu'il appartient bien à vsftpd :

root@tristram:~ # mkdir /home/vsftpd/testuser
root@tristram:~ # chown vsftpd:nobody /home/vsftpd/testuser

Connectons-nous à notre serveur FTP en utilisant Filezilla sous Windows, Konqueror ou gFTP (ou bien en ligne de commande, ftp ou lftp) sous Linux/BSD, ou encore Cyberduck sous Mac OS X. Ca marche? Parfait :-)

Maintenant le pourquoi du comment que j'ai mis 3 au lieu de 2 et MD5 au lieu de PASSWORD : tout simplement parce que ça ne fonctionne pas sous CentOS 5. L'explication vient du fichier README de pam-mysql, dispo là : /usr/share/doc/pam_mysql-0.7/README

The method to encrypt the user's password:

0 (or "plain") = No encryption. Passwords stored in plaintext. HIGHLY DISCOURAGED.

1 (or "Y") = Use crypt(3) function.

2 (or "mysql") = Use MySQL PASSWORD() function. It is possible that the encryption function used by PAM-MySQL is different from that of the MySQL server, as PAM-MySQL uses the function defined in MySQL's C-client API instead of using PASSWORD() SQL function in the query.

3 (or "md5") = Use plain hex MD5.

4 (or "sha1") = Use plain hex SHA1.

La fonction PASSWORD de MySQL et celle de pam-mysql ne renvoient donc pas le même hash de mot de passe. Dommage, hein? J'ai aussi essayé l'option 0, mais elle ne m'intéressait pas. Je n'ai pas encore essayé la fonction crypt ni la fonction sha1 pour vérifier si elles fonctionnent, mais il n'y a pas de raison ;)

Il ne reste à présent qu'à créer une page php ou un script shell qui permette de créer, modifier et effacer les utilisateurs.

Propulsé par Dotclear