4 203
modifications
« Nfs » : différence entre les versions
Aller à la navigation
Aller à la recherche
→Overview des permissions NFS
| (18 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Category:serveur]] | |||
[[Category:debian]] | |||
[[Category:networking]] | |||
[[Category:desktop]] | |||
=Installation classique= | =Installation classique= | ||
| Ligne 7 : | Ligne 11 : | ||
Pour créer un partage, éditez le fichier <code>/etc/exports</code> : | Pour créer un partage, éditez le fichier <code>/etc/exports</code> : | ||
<pre>/home/pfoo/data/ 192.168.10.0/255.255.255.0(ro, | <pre>/home/pfoo/data/ 192.168.10.0/255.255.255.0(ro,sync,no_subtree_check)</pre> | ||
Pour permettre la lecture et l'écriture, remplacez <code>ro</code> par <code>rw</code> | Note : Si l'un de vos clients doit pouvoir monter le partage nfs sans être root sur sa machine il faudra ajouter l'option <code>insecure</code> sur la ligne de l'exports. | ||
Pour permettre la lecture et l'écriture, remplacez <code>ro</code> par <code>rw</code><br> | |||
<code>192.168.10.0/255.255.255.0</code> signifie que le partage sera accessible pour les ips <code>192.168.10.X</code> | <code>192.168.10.0/255.255.255.0</code> signifie que le partage sera accessible pour les ips <code>192.168.10.X</code> | ||
| Ligne 43 : | Ligne 49 : | ||
Ajoutez la ligne suivante dans <code>/etc/fstab</code> : | Ajoutez la ligne suivante dans <code>/etc/fstab</code> : | ||
<pre>192.168.10.13:/home/pfoo/data/ /home/pfoo/mnt/ nfs defaults,user,auto,noatime,intr 0 0</pre> | <pre>192.168.10.13:/home/pfoo/data/ /home/pfoo/mnt/ nfs defaults,vers=3,user,auto,noatime,intr 0 0</pre> | ||
<code>192.168.10.13</code> est l'ip de votre serveur nfs. | <code>192.168.10.13</code> est l'ip de votre serveur nfs. | ||
| Ligne 58 : | Ligne 64 : | ||
<pre>STATDOPTS="--port 2231"</pre> | <pre>STATDOPTS="--port 2231"</pre> | ||
Modifiez la ligne suivante dans <code | Modifiez la ligne suivante dans <code>/etc/default/nfs-kernel-server</code> : | ||
<pre>RPCMOUNTDOPTS="--port 2233"</pre> | <pre>RPCMOUNTDOPTS="--port 2233"</pre> | ||
| Ligne 89 : | Ligne 95 : | ||
Et montez le partage : | Et montez le partage : | ||
<pre>mount /mnt</pre> | <pre>mount /mnt</pre> | ||
si vous souhaitez limiter la bande passante utilisable par le tunnel, utilisez trickle. Par exemple pour 5mbps : | |||
<pre> | |||
trickle -s -u 5000 -d 5000 ssh -f -i /root/.ssh/id_rsa -c blowfish -L 61001:IPNFS:2049 -l sleeper IPNFS sleep 600d | |||
trickle -s -u 5000 -d 5000 ssh -f -i /root/.ssh/id_rsa -c blowfish -L 62001:IPNFS:2233 -l sleeper IPNFS sleep 600d | |||
</pre> | |||
=Overview des permissions NFS= | |||
Le contrôle d'accès de nfs3 est basé sur les uid/gid présentés lors de chaque requete nfs. Il est important de noter que les permissions appliquées sur un partage NFS sont celles du serveur.<br> | |||
La manière classique de fonctionnement impose que les UID et les GID soient les même sur la machine cliente et sur la machine serveur nfs. Si c'est le cas, vous n'aurez aucun problème d'accès. Si vous souhaitez que l'accès soit permis en dehors du bon couple uid:gid, il faut s'intéresser aux options <code>root_squash no_root_squash all_squash no_all_squash anonuid anongid</code> de NFS. | |||
Par défaut, si rien n'est précisé, le partage est considéré comme <code>root_squash</code> et <code>no_all_squash</code>. | |||
Dans tous les exemples suivant, nous considérerons que le dossier /data appartient a l'uid:gid 1000/1000, sans aucun droit pour other (rwxr-x---) <br> | |||
Prenons un exemple simple. Si votre /etc/exports NFS est configuré comme ceci : | |||
<pre> | |||
/data 192.168.1.0/255.255.255.0(rw,sync) | |||
#ou son équivalent "par défaut" | |||
/data 192.168.1.0/255.255.255.0(rw,sync,root_squash,no_all_squash) | |||
</pre> | |||
Il faudra que l'utilisateur qui doit accéder à la ressource NFS côté client ait lui aussi l'uid 1000 et le gid 1000 (dans une moindre mesure) et ce tout simplement pour respecter les permissions linux (jusque là c'est logique, non ?). Mais Dans le cas présent, même l'utilisateur root sur le client n'aura pas les droits sur le dossier ! Bizarre ? non, c'est lié à la directive root_squash qui, en gros, remap les accès fait par l'utilisateur root sur le client vers l'uid/gid squash (numéro 65534 si ça vous intéresse).<br> | |||
Et pour qu'un autre utilisateur ait des droits, il suffit de suivre les permissions linux classiques. Mais attention, encore une fois, c'est sur le serveur qu'elles comptent. Si vous avez, sur le client nfs, un utilisateur d'uid 1001, membre du groupe de gid 1000 ... ça ne marchera pas, il faut aussi que l'utilisateur d'uid 1001 soit membre du groupe de gid 1000 sur le serveur nfs. | |||
Si nous modifions la ligne comme suit : | |||
<pre>/data 192.168.1.0/255.255.255.0(rw,sync,no_root_squash,no_all_squash)</pre> | |||
Cela permettra à l'utilisateur root d'accéder aux fichiers. Si root créé un fichier dans /data (via le client nfs évidemment), le fichier appartiendra a root:root sur le serveur. | |||
En résumé | |||
* all_squash et root_squash : force l'attribution de l'uid/gid squash aux clients | |||
* no_all_squash et no_root_squash : conserve l'uid/gid original des clients | |||
* par défaut, si rien n'est précisé : root_squash et no_all_squash. | |||
Alors, pourquoi tout ce bordel puisqu'au final il faut quand même que les userid correspondent ? C'est la qu'interviennent les directives <code>anonuid</code> et <code>anongid</code>. | |||
si on reprend, on a un dossier /data et des fichiers appartenant à l'uid 1000. Si on précise une ligne de ce type : | |||
<pre>/data 192.168.1.0/255.255.255.0(rw,sync,root_squash,all_squash,anonuid=1000,anongid=1000)</pre> | |||
Tous les utilisateurs (car all_squash) et l'utilisateur root (car root_squash) se retrouvent mappé vers l'uid squash, a savoir, l'uid 1000. Résultat, tous les utilisateurs (et root) auront les droits sur les fichiers de /data au travers de nfs. | |||
=NFS4= | |||