Chaque système de fichiers dans cette liste est suivi d'une liste d'options et d'une liste de contrôle d'accès. La liste est utilisée par exportfs(8) pour renseigner mountd(8).
Le format de ce fichier est similaire à celui du fichier exports de SunOS. Chaque ligne est composée d'un point de montage à partager, suivi d'une liste (aux éléments séparés par des espaces) de clients autorisés à monter le système de fichiers situé en ce point. Chaque client de la liste peut être immédiatement suivi par une liste d'options de partage pour ce client (entre parenthèses, les éléments étant séparés par des virgules). Aucune espace n'est tolérée entre un nom de client et sa liste d'options.
En outre, chaque ligne peut définir (après le nom du chemin) la valeur par défaut d'une ou plusieurs options, sous forme de tiret (« - ») suivi d'une liste d'options. La liste d'options est employée pour tous les partages qui suivent, sur cette ligne seulement.
Les lignes blanches sont ignorées. Un « # » indique un commentaire s'étendant jusqu'à la fin de la ligne. Les entrées peuvent s'étendre sur plusieurs lignes en utilisant la barre oblique inverse (antislash). Si un nom de partage contient des espaces, il doit être protégé par des apostrophes doubles « " ». Vous pouvez aussi utiliser la barre oblique inverse (antislash) suivi du code octal à trois chiffres pour protéger tout espace ou autre caractère inhabituel dans un nom de partage.
Pour que soient prises en compte vos modifications sur ce fichier, exécutez exportfs -ra ou redémarrez le serveur NFS.
Si un client correspond à plusieurs des configurations ci-dessus, alors la première correspondance dans l'ordre de la liste ci-dessus a la priorité – indépendamment de l'ordre d'apparition sur la ligne d'exportation. Toutefois, si un client correspond à plus d'une spécification (par exemple deux groupes réseau), alors la première correspondance dans l'ordre d'apparition sur la ligne d'exportation a la priorité.
Pour activer l'utilisation de RPC avec TLS, l'administrateur du serveur doit installer et configurer tlshd pour gérer les requêtes d'établissement de connexion de sécurité de la couche de transport à partir du noyau local. Les clients peuvent ensuite choisir d'utiliser RPC avec TLS ou de continuer à opérer sans lui.
Les administrateurs peuvent exiger l'utilisation de RPC avec TLS pour protéger l'accès aux partages individuels, ce qui est particulièrement utile lorsqu'on utilise des variantes sans sécurité chiffrée telles que sec=sys. L'option xprtsec= suivie d'une liste non ordonnée, séparée par des deux-points, de politiques de sécurité peut restreindre l'accès au partage aux seuls clients qui ont négocié la sécurité de la couche de transport. Actuellement, les politiques de sécurité de la couche de transport comprennent :
Si RPC avec TLS est configuré et activé et si l'option xprtsec=n'est pas spécifiée, la configuration par défaut pour un partage est xprtsec=none:tls:mtls. Avec cette configuration, le serveur permet aux clients d'utiliser n'importe quel mécanisme de sécurité de la couche de transport.
L'utilisation de cette option améliore généralement les performances, mais au risque de perdre ou de corrompre des données en cas de redémarrage brutal d'un serveur, suite à un plantage par exemple.
Dans toutes les versions de nfs-utils jusqu'à la 1.0.0 (incluse), async était l'option par défaut. Dans toutes les versions postérieures à 1.0.0, le comportement par défaut est sync, et async doit être explicitement indiquée si vous en avez besoin.
Définir l'option nohide sur un système de fichiers empêchera de le cacher, et tout client convenablement autorisé pourra alors se déplacer du système de fichiers parent à celui-ci sans s'en apercevoir.
Cependant, quelques clients NFS ne sont pas adaptés à cette situation. Il est alors possible, par exemple, que deux fichiers d'un système de fichiers vu comme unique aient le même numéro d'inœud.
L'option nohide ne concerne actuellement que les partages vers les hôtes seuls. Elle ne fonctionne pas de manière fiable avec les groupes de machines, les sous-réseaux et ceux utilisant les caractères jokers.
Cette option peut être très pratique dans certains cas, mais elle doit être utilisée avec parcimonie, et seulement après vérification de la capacité du système client à bien gérer cette situation.
Cette option peut être désactivée explicitement pour NFSv2 et NFSv3 avec hide.
Cette option n'est pas pertinente quand NFSv4 est utilisé. NFSv4 ne dissimule jamais les systèmes de fichiers subordonnés. Tous les systèmes de fichiers partagés seront visibles où cela est prévu lors de l'utilisation de NFSv4.
Avec nohide, le système de fichiers enfant doit être explicitement partagé. Avec crossmnt, ce n'est pas le cas. Si un enfant d'un fichier crossmnt n'est pas explicitement partagé, il sera implicitement partagé avec les mêmes options de partage que le parent, sauf pour fsid=. Cela rend impossible de ne pas partager un enfant d'un système de fichiers crossmnt. Si certains des systèmes de fichiers subordonnés d'un parent, mais pas tous, sont destinés à être partagés, ils doivent être explicitement partagés et le parent ne doit ne pas avoir crossmnt configuré.
L'option nocrossmnt peut explicitement désactiver crossmnt si elle a été définie précédemment. Cela est rarement utile.
Si un sous-répertoire d'un système de fichiers est partagé, mais que le système de fichiers ne l'est pas, alors chaque fois qu'une requête NFS arrive, le serveur doit non seulement vérifier que le fichier accédé est dans le système de fichiers approprié (ce qui est facile), mais aussi qu'il est dans l'arborescence partagée (ce qui est plus compliqué). Cette vérification s'appelle subtree_check.
Pour ce faire, le serveur doit ajouter quelques informations sur l'emplacement du fichier dans le « filehandle » (descripteur de fichier) qui est donné au client. Cela peut poser problème lors d'accès à des fichiers renommés alors qu'un client est en train de les utiliser (bien que dans la plupart des cas simples, cela continuera à fonctionner).
La vérification de sous-répertoires est également utilisée pour s'assurer que des fichiers situés dans des répertoires auxquels seul l'administrateur a accès ne sont consultables que si le système de fichiers est partagé avec l'option no_root_squash (voir ci-dessous), et ce même si les fichiers eux-mêmes offrent un accès plus général.
For more information about the security implications, refer to the Subdirectory Exports section.
D'une façon générale, un système de fichiers du répertoire personnel (« home directory »), qui est normalement partagé à sa racine et qui va subir de multiples opérations de renommage de fichiers, doit être partagé sans contrôle des sous-répertoires. Un système de fichiers principalement en lecture seule, et qui donc ne verra que peu de modifications de noms de fichiers (/usr ou /var par exemple) et pour lequel des sous-répertoires pourront être partagés, le sera probablement avec la vérification des sous-répertoires.
The default of having subtree checks disabled, can be explicitly requested with no_subtree_check.
Before release 1.1.0 of nfs-utils, the default was subtree_check. Since release 1.1.0, the default is no_subtree_check as subtree checking tends to cause more problems than it is worth. If you genuinely require subtree checking, you should explicitly put that option in the exports file. If you put neither option, exportfs will warn you that the change has occurred.
Les premières implémentations de clients NFS n'envoyaient pas d'accréditations lors de requêtes de verrouillage, et nombre de clients NFS encore utilisés sont basés sur ces anciennes implémentations. Utilisez cette option si vous constatez que vous ne pouvez verrouiller que les fichiers en lecture pour tous (« world readable »).
Par défaut, les demandes d'authentification des requêtes NLM se comportent comme si les options (synonymes) auth_nlm ou secure_locks avaient été fournies. On peut cependant écrire explicitement ces options.
Si un chemin est précisé (c'est-à-dire mountpoint=/chemin ou mp=/chemin), le chemin indiqué doit être un point de montage pour le partage qui est fait.
Puisque tous les systèmes de fichiers ne sont pas toujours stockés sur des périphériques, et qu'ils n'ont pas toujours un UUID, il sera parfois nécessaire d'indiquer comment NFS identifiera un système de fichiers. C'est le rôle de l'option fsid=.
Dans NFSv4, un système de fichiers particulier est la racine de tous les systèmes de fichiers partagés. Il est défini par fsid=root ou fsid=0, qui veulent tous deux dire exactement la même chose.
Les autres systèmes de fichiers peuvent être identifiés avec un entier court ou un UUID qui doit comporter 32 caractères hexadécimaux et une ponctuation arbitraire.
Les versions du noyau Linux 2.6.20 et précédentes ne comprennent pas les réglages UUID, l'utilisation d'un entier court est donc nécessaire pour définir l'option fsid. La définition conjointe d'un petit nombre et d'un UUID est possible pour une même configuration, ce qui rend possible l'utilisation avec d'anciens ou de nouveaux noyaux.
Cette option n'affecte que les clients NFSv4. Les autres clients ignorent toutes les parties « refer= ».
L'association entre les numéros de fsid et les chemins est stockée dans une base de données SQLite. Ne modifiez ni ne supprimez la base de données à moins que vous ne sachiez exactement ce que vous faites. predefined-fsidnum est utile quand vous avez utilisé auto-fsidnum auparavant et que vous ne voulez pas stocker davantage d'entrées.
nfsd base son contrôle d'accès aux fichiers de la machine serveur sur l'UID et le GID fournis dans chaque requête RPC de NFS. Le comportement attendu par un utilisateur est de pouvoir accéder à ses fichiers sur le serveur de la même façon qu'il y accède sur un système de fichiers normal. Ceci exige que les mêmes UID et GID soient utilisés sur le client et la machine serveur. Ce n'est pas toujours vrai, ni toujours souhaitable.
Bien souvent, il n'est pas souhaitable que l'administrateur d'une machine cliente soit également traité comme le superutilisateur lors de l'accès à des fichiers du serveur NFS. À cet effet, l'UID 0 est normalement associé (« mapped ») à un utilisateur différent : le prétendu utilisateur anonyme ou UID nobody. C'est le mode de fonctionnement par défaut (appelé « root squashing »), qui peut être désactivé grâce à no_root_squash.
Par défaut, exportfs choisit un UID et un GID de 65534 pour l'accès « squash ». Ces valeurs peuvent également être définies par les options anonuid et anongid. Enfin, vous pouvez faire correspondre toutes les demandes des utilisateurs avec l'UID anonyme en indiquant l'option all_squash.
Voici la liste complète des options de correspondance (« mapping ») :
Normalement, vous ne devriez partager que la racine d'un système de fichiers. Le serveur NFS vous permettra aussi de partager un sous-répertoire d'un système de fichiers ; cependant cela présente des inconvénients.
First, it may be possible for a malicious user to access files on the filesystem outside of the exported subdirectory, by guessing filehandles for those other files. In some cases a malicious user may also be able to access files on other filesystems that have not been exported by replacing the exported subdirectory with a symbolic link to any other directory. The only way to prevent this is by using the subtree_check option, which can cause other problems.
Ensuite, les options de partage peuvent ne pas s'appliquer comme vous vous y attendiez. Par exemple, l'option security_label ne fonctionnera pas sur des partages de sous-répertoires et si des partages de sous-répertoires imbriqués modifient les options security_label ou sec=, les clients NFSv4 ne verront normalement que les options du partage parent. Aussi quand les options de sécurité diffèrent, un client malveillant peut utiliser des attaques en devinant le descripteur de fichier pour accéder aux fichiers d'un sous-répertoire en utilisant les options d'un autre.
# exemple de fichier /etc/exports / master(rw) trusty(rw,no_root_squash) /projects proj*.local.domain(rw) /usr *.local.domain(ro) @trusted(rw) /home/joe pc001(rw,all_squash,anonuid=150,anongid=100) /pub *(ro,insecure,all_squash) /srv/www -sync,rw server @trusted @external(ro) /foo 2001:db8:9:e54::/64(rw) 192.0.2.0/24(rw) /build buildhost[0-9].local.domain(rw)
La première ligne partage l'ensemble du système de fichiers vers les machines « master » et « trusty ». En plus des droits d'écriture, toute transformation d'UID est désactivée pour l'hôte « trusty ». Les deuxième et troisième lignes montrent des exemples de noms de machines avec caractères jokers, et de groupes de machines (c'est le sens de « @trusted »). La quatrième ligne montre une entrée pour le client PC/NFS, présenté plus haut. La cinquième ligne partage un répertoire public de FTP, à toutes les machines dans le monde, en effectuant les requêtes sous le compte anonyme. L'option insecure permet l'accès aux clients dont l'implémentation NFS n'utilise pas un port réservé. La sixième ligne partage un répertoire en lecture et écriture à une machine « server » ainsi qu'à un groupe de machines « @trusted », et en lecture seule pour le groupe de machines « @external », tous les trois ayant l'option « sync » activée. La septième ligne partage un répertoire aux deux sous-réseaux IPv6 et IPv4. La huitième ligne montre une utilisation d'un caractère joker de classe.
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à