Les aventures de Heidi Map

par Martin Ouwehand, SIC-Exploitation

Introduction

Au vu des questions qui me parviennent, il semble que le système des ID-maps (où ID se prononce à l'anglaise, à peu près comme «Heidi», l'héroïne de Johanna Spyri, d'où le titre racoleur) est un aspect souvent mal compris du fonctionnement du serveur de fichiers Nestor. Cet article a donc pour but d'expliquer à quoi sert l'ID-mapping et comment ça marche.

A quoi sert l'ID-mapping?

Essentiellement à implémenter un minimum de sécurité dans l'accès par NFS (Network File System) aux fichiers du serveur Nestor. L'implémentation habituelle de NFS se base sur l'UID (un nombre entier identifiant tout utilisateur d'un système Unix) de l'utilisateur qui émet une requête d'un client NFS pour décider s'il faut permettre ou interdire l'accès aux données du serveur. Cet UID est encodé dans chaque requête NFS transitant par le réseau du client vers le serveur. La permission ou l'interdiction d'accéder aux données du serveur se base sur l'UID (et bien sûr aussi sur le GID, l'identificateur du groupe - mais nous laisserons cet aspect implicite dans la suite pour ne pas alourdir l'exposé) du propriétaire de ces données ainsi que de leurs permissions d'accès (bits rwx d'Unix). Mais de nos jours ce type de protection n'est pas suffisant puisqu'un grand nombre d'utilisateurs sont root sur leur station de travail cliente de Nestor: rien n'empêcherait un tel utilisateur malicieux ou même malveillant de créer sur sa station de travail un user ayant le même UID qu'un autre utilisateur possédant des fichiers sur le serveur et de pouvoir ainsi accéder aux données de ce dernier utilisateur, et même de les modifier ou de les effacer.
L'ID-mapping a pour but précisément de rendre impossible ce genre d'abus.

Comment ça marche?

Un certain nombre de tables d'UID résident en mémoire du serveur Nestor: ce sont ces fameuses ID-maps. Une autre table contient des paires adresse IP/ID-map. Rappelons qu'une adresse IP est un identificateur numérique de connexion au réseau: dans la vaste majorité des cas, il y a une adresse IP par ordinateur relié au réseau. Une adresse IP ne peut être appariée qu'à une ID-map au plus. A l'EPFL, il y a une ID-map par client (à quelques exceptions près), afin de permettre un contrôle d'accès avec une granularité assez fine. Ceci étant, pour chaque requête NFS traitée par le serveur, le système d'exploitation vérifie que le client a bien le droit d'accéder au serveur: son adresse IP doit figurer dans la table d'appariement mentionnée ci-dessus. Si c'est le cas, le système vérifie si l'UID de la requête figure bien dans l'ID-map correspondant à l'adresse IP du client. Si c'est le cas, la requête est considérée comme venant d'un utilisateur authentifié et elle sera satisfaite. Si l'adresse IP de la requête ne figure pas dans la table d'appariement, la requête est rejetée. Si elle y figure, mais que l'UID de la requête ne figure pas dans l'ID-map correspondante, elle sera considérée comme ayant des droits d'accès world.
Pour pouvoir accéder correctement à vos fichiers résidant sur Nestor en utilisant NFS, il faut donc que trois conditions soient remplies: que votre UID soit le même sur la machine cliente que sur le serveur Nestor, que la machine cliente soit attachée à une ID-map et que votre UID figure dans cette ID-map. C'est la raison pour laquelle il faut faire figurer votre UID (et votre GID) ainsi que la liste des clients à partir desquels vous désirez accéder à vos données sur Nestor sur le formulaire de demande d'ouverture de compte: ainsi nous pourrons mettre à jour les ID-maps adéquates pour que vous puissiez travailler confortablement. De même, si vous désirez par la suite traiter vos données depuis d'autres clients que ceux que vous aviez annoncés initialement, il faut nous le faire savoir par courrier électronique (e-mail: ouwehand@sic) en mentionnant votre nom d'utilisateur sur Nestor et le nom des machines clientes supplémentaires.
Pour tout problème de conflit d'UID ou de GID, il est bon de contacter Laurence Denoréaz (e-mail: denoreaz@sic) qui s'occupe de l'unification des UID/GID à l'EPFL.

Y aurait-il d'autres solutions?

Oui. Tout d'abord, on pourrait définir des domaines à l'intérieur desquels on estimerait que les utilisateurs peuvent se faire mutuellement confiance (par exemple, toutes les machines d'un laboratoire, d'un institut ou même d'un département), créer un file-system pour chacun de ces domaines et ne permettre l'accès à chacun de ces file-system que depuis les machines appartenant au domaine correspondant (en jouant sur les options -access ou -rw du fichier /etc/exports). Ceci aurait plusieurs inconvénients: difficulté de gestion sur le serveur d'un nombre accru de file-systems plus petits que les file-systems existants actuellement, difficulté d'échange de données par NFS entre machines appartenant à des «domaines de confiance» différents, difficulté d'estimer le degré de confiance mutuelle entre utilisateurs.
Une autre possibilité serait de contrôler de manière centralisée la création de compte sur toutes les machines clientes, par exemple par NIS (Network Information Service). Il y aurait là des difficultés d'ordre technique et d'organisation (par exemple, j'ignore si NIS serait adapté à la gestion des 900 clients actuels de Nestor), ainsi que politique (cette manière de faire froisserait un besoin d'autonomie tout à fait compréhensible des gestionnaires des machines clientes).
On pourrait encore mentionner les secure RPC ou le kerberized NFS, extensions au logiciel NFS impliquant une authentification de l'utilisateur avant de lui octroyer le droit de transférer des données par NFS. La principale difficulté de ce type de solution est qu'il implique tout un travail d'installation et de gestion d'une version modifiée de NFS sur les nombreux clients de Nestor.

Quels sont les avantages de l'ID-mapping?

Tout d'abord, atteindre le but proposé, qui est d'assurer un certain contrôle d'accès aux données résidant sur le serveur Nestor. Deuxièmement, y arriver en ayant un impact minimal sur les clients, contrairement aux autres solutions mentionnées ci-dessus: tout le travail de vérification est réalisé sur le serveur, il n'y a pas de modification ou de gestion à faire au niveau des clients. La seule contrainte est que tout utilisateur doit avoir le même UID sur les clients depuis lesquels il veut accéder à Nestor que sur le serveur même.

Quels sont les désavantages de l'ID-mapping?

Visiblement (parole d'administrateur!) ce système d'ID-maps a été conçu à une époque où le paradigme informatique consistait en quelques gros mainframes comptant un grand nombre d'utilisateurs et qu'on rebootait souvent (chaque semaine ou tous les quinze jours), alors que le paradigme actuel se traduit plutôt par une kyrielle de stations de travail reliées au réseau, comptant chacune un petit nombre d'utilisateurs et qu'on ne reboot que si nécessaire. Il en découle une certaine «staticité» dans la gestion de ces ID-maps. Par exemple, l'adresse IP est stockée statiquement en mémoire, il n'y a pas d'appel au name-server, ce qui est problématique en cas de changement d'adresse IP d'un client (ce qui arrive assez fréquemment en ces temps de recâblage). Il est possible d'ajouter un UID à une ID-map en cours d'exploitation, mais l'appartenance de cet UID à un groupe ne sera reflétée qu'au prochain reboot.
Mais tout ceci n'ennuie que le manager, qui de toute façon est là pour ça. Par contre, l'utilisateur pâtit de moins bons taux de transfert. Des mesures montrent que l'overhead dû à l'ID-mapping se situe aux alentours de 10 millisecondes, ce qui est de l'ordre de grandeur du temps de réponse à des requêtes NFS individuelles. Ceci provient en partie de la conception un peu vieillotte des ID-maps dont il a été fait mention plus haut. La recherche sur les UID est hashée (pour qu'elle soit plus rapide), alors que celle des adresses IP ne l'est pas: visiblement les concepteurs avaient en tête la situation déjà mentionnée de quelques mainframes à grand nombre d'utilisateurs. Dans l'utilisation qui en est faite à l'EPFL, il aurait été plus judicieux de hasher la recherche sur les adresses IP, puisqu'on a un grand nombre de clients ayant chacun relativement peu d'utilisateurs.
Un autre désavantage est l'obligation pour une machine d'être attachée à une ID-map pour pouvoir monter n'importe quel file-system du serveur Nestor. Il aurait été plus pratique (surtout pour /distribution, le file-system de distribution de logiciel) de donner l'accès world aux clients non-inscrits.
Nous avons transmis ces observations à Cray Research, mais les modifications de l'ID-mapping, s'il y en a, ne sont pas prévues avant la version 9.0 du système d'exploitation Unicos (prévue courant 1995).

Puis-je installer l'ID-mapping sur mon serveur?

Seulement s'il s'agit d'une machine Cray: à ma connaissance, Unicos est le seul système d'exploitation qui offre cette extension au protocole NFS.

Mes fichiers appartiennent à l'utilisateur nobody, que se passe-t-il?

C'est le symptôme que la machine sur laquelle vous constatez ce problème est bien attachée à une ID-map mais que vous ne figurez pas dans cette ID-map ou bien que votre UID sur Nestor n'est pas le même que sur la machine cliente. Dans ce dernier cas, il faudra sans doute changer votre UID sur votre machine, mais avant d'en arriver là, une bonne idée consiste à contacter Laurence Denoréaz (e-mail: denoreaz@sic) qui s'occupe de l'unification des UID/GID à l'École. Dans le premier cas, il suffit de m'envoyer un courrier électronique (e-mail: ouwehand@sic) afin que je vous fasse figurer dans l'ID-map à laquelle est attachée votre machine cliente, en spécifiant votre nom, votre nom d'utilisateur sur Nestor, votre UID ainsi que la ou les machines depuis lesquelles vous aimeriez pouvoir accéder par NFS à vos fichiers sur Nestor.

Mes fichiers appartiennent à l'UID -2 (ou 65534, ou 16777214), que se passe-t-il?

Même réponse et même remède que ci-dessus. Simplement, la manière dont votre machine cliente de Nestor vous annonce qu'il y a un problème avec l'authentification auprès de NFS (c'est-à-dire qu'il y a un problème avec les ID-maps) dépend de l'implémentation de la partie cliente de NFS sur la famille de plates-formes à laquelle appartient votre machine cliente. Jusqu'à maintenant, j'ai observé pour des utilisateurs qui ne figurent pas de manière adéquate dans les ID-maps les identificateurs nobody, -2, 65534 et 16777214 (ces deux derniers chiffres sont de la forme «puissance de deux moins deux» ­ l'exposant de la puissance dépendant apparemment du nombre de bits sur lequel sont codés les UID pour la plate-forme en question), mais il y en a peut-être d'autres.

Pour créer des fichiers à travers NFS dans mon directoire, je dois donner le droit d'écriture à world dans ce directoire, est-ce normal?

C'est une autre manifestation du problème mentionné dans les deux points précédents. Les requêtes NFS provenant d'un utilisateur ne figurant pas dans l'ID-map attachée au client à partir duquel vous travaillez sont traitées comme ayant des droits d'accès world. Le subterfuge de donner des droits d'écriture world dans le directoire où vous voulez créer des fichiers va donc fonctionner, mais c'est une mauvaise solution puisque n'importe quel utilisateur de n'importe quel client peut effacer ces fichiers. La bonne solution est donc comme ci-dessus de demander par courrier électronique (e-mail: ouwehand@sic) de pouvoir accéder correctement à Nestor (spécifier votre nom, votre username, vos UID et GID et les machines depuis lesquelles vous voulez accéder à Nestor).

Je n'arrive pas à monter un file-system de Nestor, pouvez-vous l'exporter pour ma machine?

Les file-systems de Nestor qui sont exportés (les file-systems où résident les fichiers personnels des utilisateurs, le file-system d'espace de travail temporaire /scratch ainsi que le file-system de distribution de logiciel /distribution) le sont sans restrictions (sauf /distribution, qui est exporté en mode read-only) à toutes les machines de l'École connectées au réseau et qui sont attachées à une ID-map. Ce n'est donc pas un problème d'exportation, mais un problème d'ID-map: la machine en question n'est attachée à aucune ID-map. La solution est de nouveau de m'envoyer un courrier électronique (e-mail: ouwehand@sic) spécifiant le nom de la machine ainsi que la liste des utilisateurs (avec leur UID et GID, ainsi que leur nom d'utilisateur sur Nestor) qui auront besoin d'accéder par NFS à leurs fichiers depuis cette machine pour que je puisse configurer l'ID-map adéquate. Si vous ne vous intéressez qu'au file-system de distribution de logiciel /distribution, je vous prierai de le mentionner dans votre demande (dans ce cas, il n'y a bien sûr pas lieu de donner une liste d'utilisateurs).

Dois-je demander de figurer dans une ID-map si je veux accéder à d'autres file-systems que ceux auxquels j'accède déjà?

Non. Il n'y a aucun lien entre les ID-maps et l'accès à d'autres file-systems que ceux où réside votre home-directory sur Nestor, par exemple. Le système des ID-maps contrôle globalement l'accès par NFS au serveur Nestor, ce qui signifie que si vous pouvez monter un file-system de Nestor sur votre machine cliente, vous pouvez monter tous les file-systems de Nestor qui sont exportés (dont la liste est donnée au point précédent).

Article paru dans le numéro 3-94 du Flash Informatique