Précédent     Suivant

7. Gestion des droits sur le système de fichiers NFS

Le contrôle les droits sur les objets de l'arborescence exportée par le serveur NFS est limité au masque de permissions de ces objets. Il est donc important de faire correspondre les identifiants uid et gid entre le client et le serveur.

Les manipulations suivantes sont à réaliser en «concertation» entre les administrateurs des postes client et serveur. Le compte utilisateur etu-nfs doit avoir été créé sur le serveur et sur le client.

[Note] Note

Ces manipulations se font sans système de gestion centralisé de l'authentification. L'utilisation d'un annuaire LDAP pour fournir une base de comptes utilisateurs fait l'objet d'un support de travaux pratiques qui vient après celui-ci. Ce support se concentre sur le volet système de fichiers réseau.

Q28.

Quelles sont les valeurs numériques des identifiants uid et gid du compte utilisateur etu-nfs sur le client et sur le serveur NFS ?

Si les valeurs différent entre le client et le serveur, il faut détruire ces comptes utilisateurs et reprendre les options de la commande adduser pour fournir ces valeurs de façon explicite.

L'extrait du résultat de l'instruction $ sudo adduser --help ci-dessous montre les options utiles.

adduser [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]
[--firstuid ID] [--lastuid ID] [--gecos GECOS] [--ingroup GROUP | --gid ID]
[--disabled-password] [--disabled-login] USER
   Ajoute un utilisateur normal

Reprendre la question sur la création d'un compte utilisateur local dont le répertoire est situé sur le serveur NFS.

Q29.

Sur quel poste peut on créer des fichiers et des répertoires avec des masques de permissions ayant d'autres valeurs uid et gid que celles de l'utilisateur etu-nfs ? Quelles sont les options des commandes chmod et chown à utiliser pour réaliser ces opérations ?

Utiliser les pages de manuels des commandes.

C'est sur le serveur que le super utilisateur a la possibilité de créer n'importe quel objet avec n'importe quel propriétaire dans la mesure où le système de fichiers est local et non réseau.

etu@server-nfs:~$ sudo touch /ahome/etu-nfs/ThisOneIsMine
etu@server-nfs:~$ sudo chown etu-nfs.etu-nfs /ahome/etu-nfs/ThisOneIsMine
etu@server-nfs:~$ sudo touch /ahome/etu-nfs/ThisOneIs-NOT-Mine
etu@server-nfs:~$ sudo chown 2000.2000 /ahome/etu-nfs/ThisOneIs-NOT-Mine
etu@server-nfs:~$ sudo ls -lh /ahome/etu-nfs/
total 4,0K
-rw-r--r-- 1 etu-nfs etu-nfs 18 29 août  16:15 textfile
-rw-r--r-- 1 etu-nfs etu-nfs  0 29 août  18:32 ThisOneIsMine
-rw-r--r-- 1    2000    2000  0 29 août  18:33 ThisOneIs-NOT-Mine

Côté client, les objets créés sont biens visibles et la vue réseau du système de fichiers NFS passe par une correspondance des propriétaires.

etu-nfs@client-nfs:~$ id
uid=1001(etu-nfs) gid=1001(etu-nfs) groupes=1001(etu-nfs)
etu-nfs@client-nfs:~$ ls -lh
total 4,0K
-rw-r--r-- 1 etu-nfs etu-nfs 18 29 août  16:15 textfile
-rw-r--r-- 1 etu-nfs etu-nfs  0 29 août  18:32 ThisOneIsMine
-rw-r--r-- 1    2000    2000  0 29 août  18:33 ThisOneIs-NOT-Mine

Côté client NFS, les valeurs des identifiants uid et gid sont correctement restitués et l'utilisateur n'a que le droit de lecture sur le fichier ThisOneIs-NOT-Mine.

Q30.

Quel est le service qui assure la conformité des identifiants entre serveur et client NFS ?

Reprendre la liste des service RPC actifs sur les deux systèmes.

Le démon rpc.idmapd est fourni avec le paquet nfs-common.
Précédent     Suivant
  Sommaire