Apache HTTP Server Version 1.3

Module mod_auth_msql

Ce module est implémenté dans le fichier mod_auth_msql.c et est compilé par défaut. Il permet d'appuyer la gestion de contrôle d'accès sur le moteur de base de donnée mSQL du domaine public, disponible à l'adresse ftp://ftp.bond.edu.au/pub/Minerva/msql. Ce moteur est un moteur SQL très rapide quoique limité, et auquel l'on peut se connecter via un protocole interne au domaine Unix aussi bien que par un socket classique TCP/IP. Ce module n'est disponible qu'à partir de la verison 1.1 d'Apache.

Description exhaustive / Exemple / Options de compilation / Historique des évolutions / Person to blame / Code source

Description exhaustive de tous les tokens

Auth_MSQLhost < nom_hôte | adresse_IP | localhost >: Précise la machine exécutant le moteur mSQL, par son nom d'hôte ou son adresse IP. L'UID du serveur doit avoir une autorisation d'accès à la base de données. Si non renseigné, ou si assigné au nom "magique" localhost, cette donnée est transmise à la librairie mSQL comme un pointeur NULL. A ce moment, l'utilisation de /dev/msql devient prioritaire par rapport à une communication par socket, plus lente.
Auth_MSQLdatabase < nom_base_mSQL >: Précise le nom de la base de données dans laquelle sont sensées se trouver la(les) table(s) contenant les données de contrôle d'accès (Pour une vérification rapide : utilisez la commande mSQL relshow [<nom_hôte> dbase] pour vérifier l'orthographe du nom de la base).
Auth_MSQLpwd_table < nom_table_mSQL >: Précise quelle est la table contenant les informations d'accès relatifs aux utilisateurs. Cette table contiendra au moins un champ enregistrant le nom d'utilisateur et un champ contenant le mot de passe crypté. Tout UID ne doit apparaître qu'une fois danc cette table et pour des raisons de performances, ce champ devra être une clef primaire. Cette table est en temps normal obligatoire, bien qu'il soit possible de déléguer le contrôle d'accès individuel à d'autres mécanismes et n'utiliser le module mSQL uniquement pour du contrôle de groupe. Voir la directive Auth_MSQL_Authoritative ci-après.
Auth_MSQLgrp_table < nom_table_mSQL >: Précise quelle est la table contenant les informations d'accès par groupes. Cette table contiendra au moins un champ enregistrant le nom d'utilisateur et un champ pour le nom de groupe. Un utilisateur appartenant à plusieurs groupes est donc associé à plusieurs enregistrements de cette table. Cette structure peut faire apparaître quelques problèmes quant aux performances, et l'on pourra considérer la solution consistant à créer un table par groupe, plutôt que rassembler tous les groupes dans une même table, si votre structure de répertoires le permet. Cette table ne devra être définie que dans les systèmes où un contrôle de groupe est mis en oeuvre.
Auth_MSQLuid_field < nom_champ_mSQL >: Précise quel est le nom du champ contenant les noms d'utilisateurs dans la table Auth_MSQLpwd_table et éventuellement dans la table Auth_MSQLgrp_table tables.
Auth_MSQLpwd_field < nom_champ_mSQL >: Précise quel est le nom du champ contenant les mots de passe dans la table Auth_MSQLpwd_table.
Auth_MSQLgrp_field < nom_champ_mSQL >: Précise le nom du champ contenant les noms de groupes
Il est possible de ne renseigner que les champs réellement utilisés. Lorsque ce module est compilé avec l'option BACKWARD_VITEK, alors les noms des champs accueillant les noms d'utilisateurs et les mots de passe sont nommés par défaut 'user' et 'password'. Nous vous conseillons explicitement de renommer les intitulés de ces champs par d'autres noms moins standard, ce qui opacifiera encore plus votre dispositif.
Auth_MSQL_nopasswd < on | off >: Sur 'on', saute la phase de comparaison du mot de passe si le champ de mot de passe est laissé vide dans la base. En d'autres termes, cela équivaut à accepter n'importe quel mot de passe. Cette option est 'off' par défaut de façon à interdire qu'un champ laissé vide dans la table mSQL ne permette de pénétrer le système en utilisant un mot de passe arbitraire.
Auth_MSQL_Authoritative < on | off >: Sur 'on' (par défaut), cette option interdit de déléguer le contrôle d'accès à une autre méthode d'authentification. De ce fait, si un utilisateur n'apparaît pas dans la table mSQL (ou peut être pas dans le bon groupe) ou n'a pas donné le bon mot de passe, alors l'accès lui sera systématiquement refusé.
Sur 'off', le contrôle d'accès est délégué à tout autre module de contrôle d'accès, tel que le module de contrôle d'accès de base basé sur les fichiers .htpasswd ou un module Unix-(g)dbm. Le défaut à 'on' permet d'éviter une délégation de contrôle par inadvertance, aboutissant sur une configuration non protégée. Ne désactivez cette protection qu'en parfaite connaissance de cause.
Auth_MSQL_EncryptedPasswords < on | off >: Sur 'on' (par défaut), les valeurs contenues dans le champ de mot de passe sont supposées être cryptées par la fonction crypt() implantée sur *votre* machine. Le mot de passe capturé lors de l'accès est lui-même crypté selon la même méthode avant comparaison.
Sur 'off', la comparaison port directement sur le mot de passe "en clair". (Eh oui, le schéma d'authentification http-basic-auth envoie en effet le mot de passe "en clair" :-( ). Le défaut à 'on' est la seule attitude sensée, et je pense personnellement qu'il serait une vraiment mauvaise idée de désactiver cette protection. Cependant, dans un environnement international ou partagé (qui oblige parfois à l'usage de'algorithmes de cryptages différents), vous serez peut-être parfois forcé de le faire.

Exemple

Un exemple de table mSQL pourrait être créée par les commandes suivantes :

 % msqladmin create www 
 % msql www 
 -> create table user_records ( 
 -> User_id char(32) primary key, 
 -> Cpasswd char(32),
 -> Xgroup char(32) 
 -> ) \g 
 query OK 
 -> \q 
 %

Le champ User_id peut être aussi long que nécessaire. Cependant; certains navigateurs courants tronquent le nom à 32 caractères, lorsqu'ils n'interdisent pas tout simplement la saisie d'un nom plus long. En outre, la fonction 'crypt()' de votre système peut elle-même surimposer d'autres limites. De plus, l'utilisation d'une directive require users uid [uid..] dansle fichier access.conf dans laquelle les uid sont séparés par des espaces interdira probablement l'usage d'espaces dans les noms d'utilisateurs. Voir aussi la directive MAX_FIELD_LEN ci-après.

Pour illustrer ceci, voici un exemple de ce qui pourrait être inscrit dans votre fichier access.conf. Vous trouverez également une description plus élaborée après cet exemple.

<directory /web/docs/private>

Auth_MSQLhost localhost

Auth_MSQLhost datab.machine.your.org

Si cette directive est omise ou fixée à localhost, on suppose qu'Apache et le moteur mSQL tournent sur la même machine (physique) et le canal de communication /dev/msql, plus rapide sera utilisé. Autrement, il s'agit de la machine à contacter via TCP/IP. Consultez la documentation mSQL pour plus d'informations.

Auth_MSQLdatabase www

"www" représente le nom de la base de données sur la machine spécifiée précédemment, et qui contient les deux tables de définition de contrôle d'accès pour les groupes et les utilisateurs. Il n'est actuellement pas possible de répartir ces deux tables sur deux bases de données différentes. Assurez-vous que le fichier msql.acl (fichier de contrôle d'accès aux bases de données) de mSQL autorise l'UID effectif du serveur Web à accéder à cette base de données au moins en lecture. Vous pouvez vérifier quel est cet UID dans le fichier httpd.conf.

Auth_MSQLpwd_table user_records

"user_records" est le nom de la table qui contient les combinaisons uid/password.

Auth_MSQLuid_field User_id Auth_MSQLpwd_field Cpasswd

"User_id" et "Cpasswd" sont les noms des champs de la table user_record. Si ce module est compilé sous l'option de compatibilité BACKWARD_VITEK, on considère que les noms par défaut dans cette table sont user et password à moins que vous ne le spécifiez autrement. Actuellement, le champ user_id doi être une clef primaire de la table. Si ce n'est pas le cas, vous devrez vous assurer que chaque utilisateur n'est défini qu'une et une seule fois dans cette table. Si un utilisateur est mentionné deux fois, la réaction par défaut est de refuser l'accès ; voir aussi la directive de compilation ONLY_ONCE pour plus d'informations.

Auth_MSQLgrp_table user_records Auth_MSQLgrp_field Xgroup

Si ces lignes apparaissent, alors nous utilisons une table de groupes pour enregistrer des assignations d'utilisateurs à des groupes qui peut être la même que celle utilisée pour les couples utilisateur/mot de passe (c'est le cas dans cet exemple). Cependant, si au moins un utilisateur appartient à deux groupes différents, alors on devra nécessairement créer une table séparée afin de respecter l'unicité de l'assignation utilisateur/mot de passe.

Auth_MSQL_nopasswd off Auth_MSQL_Authoritative on Auth_MSQL_EncryptedPasswords on

Nous plaçons ici les diverses options de contrôle d'accès sur leurs valeurs "sensibles". Vous n'avez même pas en fait à inscrire ces lignes puisque ce sont les valeurs par défaut. Si vous choisissez une autre valeur pour une quelconque de ces options, assurez-vous que vous en comprenez parfaitement les implications en matière de sécurité et vérifiez qu'Apache se comporte exactement comme vous vous y attendez.

AuthName example mSQL realm AuthType basic

Le contrôle d'accès se fait par les tokens standards d'Apache/NCSA :

<limit get post head>
order deny,allow
allow from all

require valid-user

valid-user donne l'accès à tout utilisateur ayant une paire uid/passwd valide dans la table pwd_table.

ou
require user smith jones

Limite l'accès aux utilisateurs ayant une paire uid/passwd valide dans la table pwd_table et dont l'UID est 'smith' ou 'jones'. Notez que la liste d'uid utilise l'espace comme séparateur pour des raisons historiques (NCSA). En conséquence, on s'abstiendra d'attribuer des noms d'utilisateurs contenant des espaces.

require group has_paid

S'assure en plus que l'UID appartient au groupe 'has_paid' dans la table des groupes.

<limit>

Options de compilation

#define ONLY_ONCE 1

Si le champ UID de la table mSQL contenant les combinaisons uid/passwd n'est pas une clef primaire, il est possible qu'un utilisateur puisse apparaître plusierus fois avec éventuellement des mots de passe différents. Lorsque ce module est compilé avec la constante ONLY_ONCE définie, tout accès est refusé à un utilisateur apparaissant plus d'une fois dans la table uid/passwd. Si vous ne définissez pas cette constante, le logiciel prendra en compte la première paire et ignorera toutes les autres. La requête SQL à utiliser est

"select password form pwd_table where user='UID'"

et qui peut conduire à des résultats non prévisibles. Pour cette raison, ainsi que pour une question de performances, il est conseillé de définir le champ UID comme clef primaire de la table uid/passwd. Choissisez en âme et conscience :-)

#define KEEP_MSQL_CONNECTION_OPEN

Normalement la connexion (TCP/IP) à la base de donnée est ouverte et refermée à chaque requête SQL. Lorsqu'Apache et la nase de données sont sur la même machine, et /dev/msql est utilisé, le gaspillage de performance est non négligeable. En outre lorsque votre système ne supporte pas ce mode rapide de connexion (voir la documentation mSQL) ou lorsque le serveur Web et la base de données se situent sur deux machines distinctes, la perte en performances peut devenir considérable. Lorsque la constante ci-dessus est définie, le serveur laissera la connexion à la base de données ouverte, c'est-à-dire qu'il ne fera pas appel à la fonction msqlClose(). Si une erreur survient, le serveur tente de réouvrir la connexion au moment de l'arrivée de la requête http suivante.

Cette technique a toutefois quelques inconvénients majeurs :

Elle coûte 2 descriptuers par processus fils, lesquels sont déjà rares.
Elle coûte des connexions msql (typiquement une par fils). Le nombre de connexions (valeur compilée) que mSQL peut accepter est assez faible, en général 6 ou 12, ce qui peut interdire à de nouveaux processus httpd d'accéder à la base de données mSQL.
Lorsqu'un fils httpd meurt, il se peut qu'il ne referme pas la connexion proprement, ou suffisamment vite.
Lorsque des erreurs commencent à apparaître, les ressources en termes de nombre de connexions/descripteurs de fichiers peuvent être rapidement saturées.

En bref, utilisez cette technique à vos risques et périls et seulement dans un contexte ultra contrôlé et suivi.

#define BACKWARD_VITEK #define VITEK_uid_name "user" #define VITEK_gid_name "passwd"

Un second module de contrôle d'accès par mSQL pour Apache a été développé par Vivek Khera <khera@kciLink.com> et a été alors distribué avec des versions premières d'Apache. Il peut être téléchargé à partir de ftp://ftp.kcilink.com/pub/mod_auth_msql.c*. Des versions 'vitek' anciennes avaient les noms des tables et des champs codés en dur dans le code. Les versions plus récentes, v.1.11 disposent de plus d'options de configuration par access.conf. Cependant, ces options ont été constituées pour rester cohérent avec les premières versions de ce module. En outre, le module 'vitek' ne donne pas l'accès de groupe ne l'accès pour des mots de passe 'vides'.

Afind e rester un peu plus cohérent, cette version(0.9) est rétro-compatible avec le module 'vitek' en :

Ajoutant le support de la fonctionnalité Auth_MSQL_EncryptedPasswords on/off.
Ajoutant le support des différentes syntaxes pour les 4 tokens de configuration user-table-name, user/password-field-name et dbase-name.
Acceptant des noms de champs par défaut compatibles avec les noms codés en dur dans les anciennes versions du module 'vitek'.

Si cela vous laisse perplexe, enlevez le #define 'BACKWARD_VITEK'.

#define MAX_FIELD_LEN (64) #define MAX_QUERY_LEN (32+24+MAX_FIELD_LEN*2+3*MSQL_FIELD_NAME_LEN+1*MSQL_TABLE_NAME_LEN)

De sorte à éviter d'utiliser l'énorme HUGE_STRING_LENGTH, les deux options de compilation suivantes sont fournies. La définition MAX_FIELD_LEN précise le nombre maximum de caractères pour le nom de votre utilisateur, de son mot de passe et du champ de nom de groupe. La longueur maximale de requête est dérivée de ces valeurs.

Apache ne lance que les deux requêtes suivantes :

Pour une requête sur les combinaisons uid/passwd
"select PWDFIELD from PWDTABLE where USERFIELD='UID'"
Eventuellement, pour les combinaisons uid/gid :
"select GROUPFIELD from GROUPTABLE where USERFIELD='UID' and GROUPFIELD='GID'"

de ceci l'ont déduit la taille maximale de la requête. Nous ignorons quelque peu l'usage de caractères d'échappement et supposons qu'il n'y en a pas plus de 24.

Revision History

This version: 23 Nov 1995, 24 Feb 1996, 16 May 1996.

Version 0.0: Première version
Version 0.1: Mise à jour vers Apache 1.00
Version 0.2: Ajout de lignes de codes disparues Dieu seul sait comment et qui flanquait par terre l'authentification valid-user !
Version 0.3: Ajout de l'option 'Auth_MSQL_nopasswd'
Version 0.4: Nettoyage des messages d'erreur.
Version 0.6: Certaines erreurs avec le gid/grp Assurez-vous d'utiliser le 'Auth_MSQLgrp_field' comme mentionné ci-avant.
Version 0.7: host vers host corrigé. Merci à Rob Stout, <stout@lava.et.tudelft.nl> pour l'avoir déniché.
Version 0.8: Ajout de la directive Authoritative. Voir ci-avant.
Version 0.9: Vérification du code de retour de palloc(), devrait assurer la rétro-compatibilité avec la version 1.11 du module msql de Vivek Khera <khera@kciLink.com>, message d'erreur erroné dans le contrôel de groupe, les messages de commandes de table ont été changés pour les rendre plus significatifs lorsqu'affichés dans ce nouveau module de management. Ajout de la fonctionnalité Auth_MSQL_EncryptedPasswords on/off. Ajout du déclenchement de msqlClose() sur constat d'erreur. Support des connexions persistantes avec la base de données mSQL (risqué !). Echappement des caractères ' et \. Certaines erreurs en rapport avec MAX_STRING_LENGTH ont été fixées.

Contact/Personne à lincher ;-)

Ce module a été écrit pour l'European Wide Service Exchange par <Dirk.vanGulik@jrc.it>. Contactez-moi pour le moindre problème, ou bug. Cette documentation est due à Nick Himba, <himba@cs.utwente.nl>.

Code source

Le code source pourra être consulté à l'adresse


http://www.apache.org

. Une image d'une version de travail est disponible à l'adresse http://me-www.jrc.it/~dirkx/mod_auth_msql.c. Assurez-vous de bien mentionner quelle version vous utilisez lorsque vous nous envoyez un rapport d'erreur.

De plus un package de test et démonstration (ce qui suppose que vous avez déjà compilé et installé Apache et mSQL) peut être récupérée à l'adresse contributive ftp://ftp.apache.org/apache/dist/contrib ou http://me-www.jrc.it/~dirkx/apache-msql-demo.tar.gz avec son fichier README file.

Apache HTTP Server Version 1.3