4 203
modifications
« Nfs » : différence entre les versions
Aller à la navigation
Aller à la recherche
→Overview des permissions NFS
| Ligne 103 : | Ligne 103 : | ||
=Overview des permissions NFS= | =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. | |||
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 | |||
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> | |||