Une solution possible, si chaque utilisateur a une station dédiée, et que chaque station de travail
ne serve qu'à un seul utilisateur, et de forcer un all_squash (et non pas seulement un root_squash,
pour le probleme du su justement) avec comme uid/gid forcé celui de l'utilisateur.
Il faut donc une ligne d'export pour chaque station/utilisateur, du genre:
Ainsi, le serveur NFS considere que tous les acces depuis machine_de_ptramo se font avec l'uid de ptramo,
que l'utilisateur distant soit ptramo, root ou toto.
La "sécurisation" est donc faite par l'IP au lieu de l'uid déclarée du client... Bien sûr c'est toujours
contournable en changeant son IP... donc c'est pas encore ça :/ mais c'est une barriere de plus (l'admin peut au moins mettre en place la vérification de cohérence entre IP et adresse ethernet... zut c'est spoofable aussi...)
# all_squash
Posté par daggett . En réponse au journal Administrateurs, Sécurité et NFS. Évalué à 3.
ne serve qu'à un seul utilisateur, et de forcer un all_squash (et non pas seulement un root_squash,
pour le probleme du su justement) avec comme uid/gid forcé celui de l'utilisateur.
Il faut donc une ligne d'export pour chaque station/utilisateur, du genre:
/exports/home/ machine_de_toto.domaine(rw,all_squash,anonuid=uid_de_toto,anongid=gid_de_toto)
/exports/home/ machine_de_ptramo.domaine(rw,all_squash,anonuid=uid_de_ptramo,anongid=gid_de_ptramo)
Ainsi, le serveur NFS considere que tous les acces depuis machine_de_ptramo se font avec l'uid de ptramo,
que l'utilisateur distant soit ptramo, root ou toto.
La "sécurisation" est donc faite par l'IP au lieu de l'uid déclarée du client... Bien sûr c'est toujours
contournable en changeant son IP... donc c'est pas encore ça :/ mais c'est une barriere de plus (l'admin peut au moins mettre en place la vérification de cohérence entre IP et adresse ethernet... zut c'est spoofable aussi...)