Ce face opțiunea NO_ALL_SQUASH în exporturile NFS?

De la pagina de manual exports(5)., în secțiunea „Mapping ID utilizator”, scrie:

Maparea ID-ului utilizatorului

...

Foarte des, nu este de dorit ca utilizatorul root de pe o mașină client să fie tratat și ca root atunci când accesează fișierele de pe serverul NFS. În acest scop, uid 0 este în mod normal mapat la un id diferit: așa-numitul anonim sau nimeni uid. Acest mod de operare (numit „root squashing”) este implicit și poate fi dezactivat cu no_root_squash.

...

Iată lista completă a opțiunilor de cartografiere:

rădăcină_dovleac

Hartați solicitările de la uid/gid 0 la uid/gid anonim. Rețineți că acest lucru nu se aplică altor uid-uri sau gid-uri care ar putea fi la fel de sensibile, cum ar fi utilizatorul cos sau grup personal.

no_root_squash

Opriți strivirea rădăcinilor. Această opțiune este utilă în principal pentru clienții fără disc.

all_squash

Hartați toate uid-urile și ghidurile către utilizatorul anonim. Util pentru directoarele FTP publice exportate prin NFS, directoarele spool de știri etc. Opțiunea opusă este no_all_squash, care este setarea implicită.

...

Am rezumat opțiunile de mapare UID în următorul tabel (presupus 1000 să fie UID-ul unui utilizator neprivilegiat și 65534 pentru a fi UID-ul anonim):

Root squash/no root squash nu are nicio legătură cu ID-ul clientului pe care îl veți vedea când faceți citirea/scrierea, doar dacă root-ul are sau nu permisiunea să intre și să facă modificări, indiferent dacă este sau nu inclus în permisiune a stabilit. Root squash va împiedica rădăcina locală să schimbe dreptul de proprietate asupra fișierelor.

În general, root squash este oprit, cu excepția cazului în care există un motiv de securitate presant pentru a lega fișierele anumitor utilizatori. Se presupune că rădăcina este protejată, iar utilizatorii se presupune că nu au acces root. Dacă datele privind cota trebuie menținute la nivelul cotei, atunci dovleceul rădăcină poate fi de dorit.

După ce am configurat o pereche de server și client NFS într-un mediu virtual, am găsit următorul rezultat:

Cu alte cuvinte, no_all_squash opțiunea pare să se comporte la fel ca și rădăcină_dovleac opțiune. Acesta răspunde la întrebarea 1 și explică întrebarea 2 în același timp.

Abordarea obișnuită este de a permite maparea rădăcină între mașini. Mai mult, vechea abordare moștenită NFS folosea NIS pentru a sincroniza ID-urile utilizatorului într-un domeniu NIS exact în acest scop: în caz contrar, aceiași utilizatori cu ID-uri diferite ar fi confundați unul pentru celălalt.

Squashing este folosit în unele cazuri rare când, pe de o parte, doriți să permiteți accesul NFS unor clienți care nu sunt a ta, și pe de altă parte, nu doriți ca aceștia să aibă acces deplin dacă folosesc id 0. De obicei, NFS este configurat în rețeaua unei singure organizații, unde toate prelucratele sunt administrate de o echipă de ingineri.

Ca despre toate/niciunul squashing/no-squashing - finalul a fost simplu: atunci când doriți să aplicați niște ACL-uri complicate pentru arborele sistemului de fișiere, trebuie să utilizați NFSv4 care gestionează corect ACL, deoarece NFSv<=3 pur și simplu nu o face, cu sau fără squashing (aceasta din urmă face doar modelul de acces NFSv<=3 greoi, dar nu complet). Ultima parte a fost principalul motiv pentru care a apărut NFSv4 până la urmă.