Provided by: manpages-ro_4.28.0-2_all 
NUME
exports - tabelul de export al serverului NFS
DESCRIERE
Fișierul /etc/exports conține un tabel al sistemelor de fișiere fizice locale de pe un server NFS care
sunt accesibile clienților NFS. Conținutul fișierului este menținut de administratorul de sistem al
serverului.
Fiecare sistem de fișiere din acest tabel are o listă de opțiuni și o listă de control al accesului.
Tabelul este utilizat de exportfs(8) pentru a furniza informații către mountd(8).
Formatul fișierului este similar cu cel al fișierului exportsal SunOS. Fiecare linie conține un punct de
export și o listă separată prin spații albe a clienților cărora li se permite să monteze sistemul de
fișiere la acel punct. Fiecare client enumerat poate fi urmat imediat de o listă de opțiuni de export
pentru clientul respectiv, separate prin virgule și puse între paranteze. Nu sunt permise spații albe
între un client și lista sa de opțiuni.
De asemenea, fiecare linie poate avea una sau mai multe specificații pentru opțiuni implicite după numele
rutei, sub forma unei liniuțe („-”) urmată de o listă de opțiuni. Lista de opțiuni este utilizată numai
pentru toate exporturile ulterioare pe linia respectivă.
Liniile goale sunt ignorate. Semnul lirei („#”) introduce un comentariu la sfârșitul liniei.
Înregistrările pot fi continuate pe linii noi folosind o bară oblică inversă. Dacă un nume de export
conține spații, acesta trebuie să fie pus între ghilimele duble. De asemenea, puteți specifica spații sau
alte caractere neobișnuite în numele de export folosind o bară oblică inversă urmată de codul
caracterului sub forma a trei cifre octale.
Pentru a aplica modificările la acest fișier, executați exportfs -ra sau reporniți serverul NFS.
Formate pentru numele mașinii
Clienții NFS pot fi specificați în mai multe moduri:
single host - (o singură gazdă)
Puteți specifica o gazdă fie printr-un nume abreviat recunoscut de rezolvator, fie printr-un nume
de domeniu complet calificat, o adresă IPv4 sau o adresă IPv6. Adresele IPv6 nu trebuie să se afle
între paranteze drepte în „/etc/exports” pentru a nu fi confundate cu potriviri de caractere de
tip joker.
IP networks - (rețele IP)
De asemenea, puteți exporta simultan directoare către toate gazdele dintr-o (sub)rețea IP. Acest
lucru se realizează prin specificarea unei adrese IP și a unei perechi de măști de rețea ca
adresă/mască de rețea, unde masca de rețea poate fi specificată în format zecimal punctat sau ca o
lungime de mască contiguă. De exemplu, fie „/255.255.252.0”, fie „/22” adăugate la adresa IPv4 de
bază a rețelei rezultă subrețele identice cu 10 biți de gazdă. Adresele IPv6 trebuie să utilizeze
o lungime de mască contiguă și nu trebuie să se afle între paranteze drepte pentru a evita
confuzia cu caracterele joker de clasă. Caracterele joker nu funcționează în general cu adresele
IP, deși pot funcționa accidental atunci când căutările DNS inverse eșuează.
wildcards - (caractere joker)
Numele mașinilor pot conține caracterele joker * și ? sau pot conține liste de clase de caractere
între [paranteze drepte]. Acest lucru poate fi utilizat pentru a face fișierul exports mai
compact; de exemplu, *.cs.foo.edu corespunde tuturor gazdelor din domeniul cs.foo.edu. Deoarece
aceste caractere se potrivesc și cu punctele dintr-un nume de domeniu, modelul dat se va potrivi
și cu toate gazdele din orice subdomeniu al cs.foo.edu.
netgroups - (grupuri de rețea)
Grupurile de rețea NIS pot fi date ca @group. Numai partea de gazdă a fiecărui membru al grupului
de rețea este luată în considerare pentru verificarea apartenenței. Părțile de gazdă goale sau
cele care conțin o singură liniuță (-) sunt ignorate.
anonymous - (anonim)
Aceasta este specificată printr-un singur caracter * (a nu se confunda cu caractere joker de mai
sus) și se va potrivi tuturor clienților.
Dacă un client corespunde mai multor specificații de mai sus, prima potrivire din lista de mai sus are
prioritate - indiferent de ordinea în care apar în linia de export. Cu toate acestea, în cazul în care un
client corespunde mai multor specificații de același tip (de exemplu, două grupuri de rețele), atunci are
prioritate prima potrivire din ordinea în care apar pe linia de export.
Securitatea RPCSEC_GSS
Puteți utiliza șirurile speciale „gss/krb5”, „gss/krb5i” sau „gss/krb5p” pentru a restricționa accesul
clienților care utilizează securitatea rpcsec_gss. Cu toate acestea, această sintaxă este depreciată; pe
nucleele linux începând cu versiunea 2.6.23, ar trebui să utilizați în schimb opțiunea de export „sec=”:
sec= Opțiunea sec=, urmată de o listă de tipuri de securitate delimitată prin două puncte,
restricționează exportul la clienții care utilizează respectivele tipuri. Tipurile de securitate
disponibile includ sys (implicit - nicio securitate criptografică), krb5 (doar autentificare),
krb5i (protecție a integrității) și krb5p (protecție a confidențialității). În scopul negocierii
variantelor de securitate, ordinea contează: variantele preferate ar trebui să fie enumerate
primele. Ordinea opțiunii sec= în raport cu celelalte opțiuni nu contează, cu excepția cazului în
care doriți ca anumite opțiuni să fie aplicate în mod diferit în funcție de varianta de
securitate. În acest caz, puteți include mai multe opțiuni sec=, iar următoarele opțiuni vor fi
puse în aplicare numai pentru accesul care utilizează variantele enumerate în opțiunea sec=
imediat anterioară. Singurele opțiuni care pot varia în acest mod sunt ro, rw, no_root_squash,
root_squash și all_squash.
Securitatea stratului de transport
Serverul NFS Linux permite utilizarea RPC-cu-TLS (RFC 9289) pentru a proteja traficul RPC între el și
clienții săi. Alternativ, administratorii pot securiza traficul NFS utilizând un VPN, un tunel ssh sau un
mecanism similar, într-un mod transparent pentru server.
Pentru a permite utilizarea RPC-cu-TLS, administratorul serverului trebuie să instaleze și să configureze
tlshd pentru a gestiona cererile de negociere privind securitatea stratului de transport de la nucleul
local. Clienții pot alege apoi să utilizeze RPC-cu-TLS sau pot continua să funcționeze fără aceasta.
Administratorii pot solicita utilizarea RPC-cu-TLS pentru a proteja accesul la exporturi individuale.
Acest lucru este deosebit de util atunci când se utilizează variante de securitate necriptografice, cum
ar fi sec=sys. Opțiunea xprtsec=, urmată de o listă neordonată delimitată de două puncte de politici de
securitate, poate restricționa accesul la export numai pentru clienții care au negociat securitatea
stratului de transport. Politicile de securitate a stratului de transport acceptate în prezent includ:
none Serverul permite clienților să acceseze exportul fără a utiliza securitatea stratului de
transport.
tls Serverul permite clienților care au negociat o sesiune RPC-cu-TLS fără autentificare „peer” (numai
confidențialitate) să acceseze exportul. Clienții nu sunt obligați să ofere un certificat x.509
atunci când stabilesc o sesiune de securitate a stratului de transport.
mtls Serverul permite clienților care au negociat o sesiune RPC-cu-TLS cu autentificare „peer”să
acceseze exportul. Serverul solicită clienților să ofere un certificat x.509 atunci când stabilesc
o sesiune de securitate a stratului de transport.
Dacă RPC-cu-TLS este configurat și activat și opțiunea xprtsec= nu este specificată, valoarea implicită
pentru un export este xprtsec=none:tls:mtls. Cu această definiție, serverul permite clienților să
utilizeze orice mecanism de securitate a stratului de transport sau niciunul pentru a accesa exportul.
Opțiuni generale
exportfs înțelege următoarele opțiuni de export:
secure Această opțiune impune ca cererile care nu utilizează gss să provină de pe un port Internet mai
mic decât IPPORT_RESERVED (1024). Această opțiune este activată în mod implicit. Pentru a o
dezactiva, specificați insecure. (NOTĂ: nucleele mai vechi (înainte de versiunea 4.17 a nucleului
din amonte) impuneau această cerință și pentru cererile gss).
rw Permite atât cererile de citire, cât și cele de scriere pe acest volum NFS. Valoarea implicită
este de a nu permite nicio cerere care modifică sistemul de fișiere. Acest lucru poate fi, de
asemenea, făcut explicit prin utilizarea opțiunii ro.
async Această opțiune permite serverului NFS să încalce protocolul NFS și să răspundă la solicitări
înainte ca orice modificări aduse de solicitarea respectivă să fi fost înregistrate în stocarea
stabilă (de exemplu, unitatea de disc).
Utilizarea acestei opțiuni îmbunătățește de obicei performanța, dar cu prețul că o repornire
necurățată a serverului (de exemplu, o prăbușire) poate cauza pierderea sau deteriorarea datelor.
sync Răspunde la solicitări numai după ce modificările au fost introduse în stocarea stabilă (a se
vedea async de mai sus).
În versiunile de nfs-utils până la 1.0.0 inclusiv, opțiunea async a fost cea implicită. În toate
versiunile după 1.0.0, sync este opțiunea implicită, iar async trebuie solicitată explicit dacă
este necesar.
no_wdelay
Această opțiune nu are niciun efect dacă async este de asemenea definită. Serverul NFS va întârzia
în mod normal cu puțin comiterea unei cereri de scriere pe disc dacă suspectează că o altă cerere
de scriere conexă poate fi în curs sau poate sosi în curând. Acest lucru permite transmiterea mai
multor cereri de scriere pe disc cu o singură operație, ceea ce poate îmbunătăți performanța. Dacă
un server NFS primește în principal cereri mici fără legătură, acest comportament ar putea reduce
de fapt performanța, astfel încât no_wdelay este disponibilă pentru a o dezactiva. Valoarea
implicită poate fi solicitată explicit cu opțiunea wdelay.
nohide Această opțiune se bazează pe opțiunea cu același nume oferită în NFS IRIX. În mod normal, dacă un
server exportă două sisteme de fișiere, dintre care unul este montat pe celălalt, clientul va
trebui să monteze explicit ambele sisteme de fișiere pentru a avea acces la ele. Dacă montează
doar părintele, va vedea un director gol în locul în care este montat celălalt sistem de fișiere.
Acest sistem de fișiere este „ascuns”.
Definirea opțiunii nohide pe un sistem de fișiere face ca acesta să nu fie ascuns, iar un client
autorizat corespunzător va putea să treacă de la sistemul părinte la acel sistem de fișiere fără
să observe schimbarea.
Cu toate acestea, unii clienți NFS nu se descurcă bine cu această situație deoarece, de exemplu,
este posibil ca două fișiere din același sistem de fișiere aparent să aibă același număr de nod-i.
Opțiunea nohide este eficientă în prezent numai pentru exporturile către o singură gazdă. Aceasta
nu funcționează în mod fiabil cu exporturile către grupuri de rețea, sub-rețea sau clienți numiți
cu ajutorul caracterelor joker.
Această opțiune poate fi foarte utilă în anumite situații, dar trebuie utilizată cu atenția
cuvenită și numai după confirmarea faptului că sistemul client face față situației în mod
eficient.
Opțiunea poate fi dezactivată explicit pentru NFSv2 și NFSv3 cu hide.
Această opțiune nu este relevantă atunci când se utilizează NFSv4. NFSv4 nu ascunde niciodată
sistemele de fișiere subordonate. Orice sistem de fișiere care este exportat va fi vizibil acolo
unde este de așteptat atunci când se utilizează NFSv4.
crossmnt
Această opțiune este similară cu nohide, dar permite clienților să acceseze toate sistemele de
fișiere montate pe un sistem de fișiere marcat cu crossmnt. Astfel, atunci când un sistem de
fișiere copil „B” este montat pe un sistem părinte „A”, activarea opțiunii crossmnt pe «A» are un
efect similar cu activarea opțiunii „nohide” pe B.
Cu nohide sistemul de fișiere copil trebuie să fie exportat explicit. Cu crossmnt nu este necesar.
Dacă un copil al unui fișier crossmnt nu este exportat explicit, atunci acesta va fi exportat
implicit cu aceleași opțiuni de export ca și părintele, cu excepția fsid=. Acest lucru face
imposibil să nu se exporte un copil al unui sistem de fișiere crossmnt. Dacă unele, dar nu toate
sistemele de fișiere subordonate unui părinte trebuie să fie exportate, atunci acestea trebuie să
fie exportate explicit, iar părintelui nu trebuie să i se definească crossmnt.
Opțiunea nocrossmnt poate dezactiva în mod explicit crossmnt dacă a fost definită anterior. Acest
lucru este rareori util.
subtree_check
Această opțiune activează verificarea subarborelui, care poate avea ușoare beneficii de
securitate, dar poate reduce fiabilitatea în anumite circumstanțe.
Dacă un subdirector dintr-un sistem de fișiere este exportat, dar întregul sistem de fișiere nu
este, atunci de fiecare dată când sosește o cerere NFS, serverul trebuie să verifice nu numai dacă
fișierul accesat se află în sistemul de fișiere corespunzător (ceea ce este ușor), ci și dacă se
află în arborele exportat (ceea ce este mai greu). Această verificare se numește subtree_check.
Pentru a efectua această verificare, serverul trebuie să includă unele informații despre locația
fișierului în „filehandle” care este dat clientului. Acest lucru poate cauza probleme la accesarea
fișierelor care sunt redenumite în timp ce un client le are deschise (deși în multe cazuri simple
va funcționa în continuare).
verificarea subarborelui este, de asemenea, utilizată pentru a se asigura că fișierele din
interiorul directoarelor la care doar root are acces pot fi accesate numai dacă sistemul de
fișiere este exportat cu no_root_squash (a se vedea mai jos), chiar dacă fișierul în sine permite
un acces mai general.
Pentru mai multe informații despre implicațiile de securitate, consultați secțiunea «Exporturi de
subdirectoare».
Ca un ghid general, un sistem de fișiere de tip „director personal”, care este în mod normal
exportat la rădăcină și în care pot apărea multe redenumiri de fișiere, ar trebui să fie exportat
cu verificarea sub-arborelui dezactivată. Un sistem de fișiere care este în cea mai mare parte de
tip numai-citire și pentru care cel puțin nu există multe redenumiri de fișiere (de exemplu,
„/usr” sau „/var”) și pentru care subdirectoarele pot fi exportate, ar trebui probabil să fie
exportat cu verificarea sub-arborelui activată.
Verificările implicite ale subarborelui sunt dezactivate și pot fi solicitate explicit cu
no_subtree_check.
Înainte de versiunea 1.1.0 a nfs-utils, valoarea implicită era subtree_check. De la versiunea
1.1.0, opțiunea implicită este no_subtree_check, deoarece verificarea subarborelui tinde să
cauzeze mai multe probleme decât merită. Dacă aveți într-adevăr nevoie de verificarea
subarborelui, trebuie să introduceți explicit această opțiune în fișierul exports. Dacă nu
introduceți nicio opțiune, exportfs vă va avertiza că modificarea a avut loc.
insecure_locks
no_auth_nlm
Această opțiune (cele două nume sunt sinonime) indică serverului NFS să nu solicite autentificarea
cererilor de blocare (adică cererile care utilizează protocolul NLM). În mod normal, serverul NFS
va solicita ca o cerere de blocare să dețină o acreditare pentru un utilizator care are acces de
citire la fișier. Cu această opțiune nu se va efectua nicio verificare a accesului.
Implementările anterioare ale clienților NFS nu trimiteau acreditări cu cererile de blocare și
există încă mulți clienți NFS actuali care se bazează pe implementările vechi. Utilizați acest
fanion dacă constatați că puteți bloca numai fișiere care pot fi citite de toată lumea.
Comportamentul implicit de a solicita autentificarea pentru cererile NLM poate fi solicitat în mod
explicit cu oricare dintre sinonimele auth_nlm sau secure_locks.
mountpoint=ruta
mp Această opțiune face posibilă exportarea unui director numai dacă acesta a fost montat cu succes.
Dacă nu este indicată nicio rută (de exemplu, mountpoint sau mp), atunci punctul de export trebuie
să fie și un punct de montare. Dacă nu este, atunci punctul de export nu este exportat. Acest
lucru vă permite să vă asigurați că directorul de sub un punct de montare nu va fi niciodată
exportat accidental dacă, de exemplu, sistemul de fișiere nu a reușit să se monteze din cauza unei
erori de disc.
Dacă este furnizată o rută (de exemplu, mountpoint=/ruta sau mp=/ruta), atunci ruta nominalizată
trebuie să fie un punct de montare pentru punctul de export care urmează să fie exportat.
fsid=num|root|uuid
NFS needs to be able to identify each filesystem that it exports. Normally it will use a UUID for
the filesystem (if the filesystem has such a thing) or the device number of the device holding the
filesystem (if the filesystem is stored on the device).
Deoarece nu toate sistemele de fișiere sunt stocate pe dispozitive și nu toate sistemele de
fișiere au UUID-uri, uneori este necesar să se indice explicit lui NFS cum să identifice un sistem
de fișiere. Acest lucru se face cu opțiunea fsid=.
Pentru NFSv4, există un sistem de fișiere distinct care este rădăcina tuturor sistemelor de
fișiere exportate. Acesta este specificat cu fsid=root sau fsid=0, ambele însemnând exact același
lucru.
Alte sisteme de fișiere pot fi identificate cu un mic număr întreg sau un UUID care ar trebui să
conțină 32 de cifre hexazecimale și punctuație arbitrară.
Nucleele Linux versiunea 2.6.20 și anterioare nu înțeleg definiția UUID, astfel încât trebuie
utilizat un număr întreg mic dacă o opțiune FSID trebuie să fie definită pentru astfel de nuclee.
Se acceptă atât definirea unui număr mic, cât și a unui UUID, astfel încât aceeași configurație să
poată funcționa atât pe nucleele vechi, cât și pe cele noi.
nordirplus
Această opțiune va dezactiva gestionarea cererilor READDIRPLUS. Atunci când este activată,
cererile READDIRPLUS de la clienții NFS returnează NFS3ERR_NOTSUPP, iar clienții revin la READDIR.
Această opțiune afectează numai clienții NFSv3.
refer=ruta@gazda[+gazda][:ruta@gazda[+gazda]]
Un client care face referire la punctul de export va fi direcționat să aleagă din lista dată o
locație alternativă pentru sistemul de fișiere. (Rețineți că serverul trebuie să aibă un punct de
montare aici, deși nu este necesar un sistem de fișiere diferit; astfel, de exemplu, mount --bind
/ruta /ruta este suficient).
Această opțiune afectează numai clienții NFSv4. Alți clienți vor ignora toate părțile „refer=”.
replicas=ruta@gazda[+gazda][:ruta@gazda[+gazda]]
Dacă clientul solicită locații alternative pentru punctul de export, i se va oferi această listă
de alternative. (Rețineți că replicarea efectivă a sistemului de fișiere trebuie gestionată în
altă parte).
pnfs Această opțiune permite utilizarea extensiei pNFS dacă nivelul protocolului este NFSv4.1 sau
superior, iar sistemul de fișiere acceptă exporturile pNFS. Cu pNFS, clienții pot ocoli serverul
și pot efectua operații de In/Ieș direct către dispozitivele de stocare. Valoarea implicită poate
fi solicitată explicit cu opțiunea no_pnfs.
security_label
Cu această opțiune activată, clienții care utilizează NFSv4.2 sau o versiune mai recentă vor putea
defini și prelua etichete de securitate (precum cele utilizate de SELinux). Acest lucru va
funcționa numai dacă toți clienții utilizează o politică de securitate consecventă. Rețineți că
primele nuclee nu acceptau această opțiune de export și, în schimb, activau etichetele de
securitate în mod implicit.
reexport=auto-fsidnum|predefined-fsidnum
Această opțiune ajută atunci când o partajare NFS este reexportată. Deoarece serverul NFS are
nevoie de un identificator unic pentru fiecare sistem de fișiere exportat, iar o partajare NFS nu
poate furniza un astfel de identificator, de obicei este necesar un fsid manual. De îndată ce
crossmnt este utilizată, atribuirea manuală a fsid nu va mai funcționa. Acesta este momentul în
care această opțiune devine utilă. Aceasta va atribui automat un fsid numeric partajărilor NFS
exportate. Relațiile fsid și ruta sunt stocate într-o bază de date SQLite. Dacă se selectează
auto-fsidnum, fsid-ul este, de asemenea, alocat automat. predefined-fsidnum presupune numere fsid
prealocate și le va căuta pur și simplu. Această opțiune depinde și de nucleu, veți avea nevoie
cel puțin de versiunea 5.19 a nucleului. Deoarece reexport= poate aloca și atribui automat fsids
numerice, nu mai este posibil să aveți fsids numerice în alte exporturi de îndată ce această
opțiune este utilizată în cel puțin o intrare de export.
Asocierea dintre numerele fsid și rute este stocată într-o bază de date SQLite. Nu editați sau
eliminați baza de date decât dacă știți exact ce faceți.predefined-fsidnum este utilă atunci când
ați folosit auto-fsidnum înainte și nu doriți să stocați alte intrări.
Corespondența ID-ului de utilizator
nfsd își bazează controlul accesului la fișierele de pe mașina server pe uid și gid furnizate în fiecare
cerere NFS RPC. Comportamentul normal la care s-ar aștepta un utilizator este acela de a-și putea accesa
fișierele de pe server la fel cum ar face-o pe un sistem de fișiere normal. Acest lucru necesită
utilizarea acelorași uid și gid pe mașinile client și server. Acest lucru nu este întotdeauna adevărat și
nici nu este întotdeauna de dorit.
De foarte multe ori, nu este de dorit ca utilizatorul root de pe o mașină client să fie tratat ca root și
atunci când accesează fișiere de pe serverul NFS. În acest scop, uid 0 este în mod normal asociat cu un
id diferit: așa-numitul uid anonim sau nobody. Acest mod de operare (numit „root squashing”) este
implicit și poate fi dezactivat cu no_root_squash.
În mod implicit, exportfs alege un uid și un gid de 65534 pentru accesul squashed. Aceste valori pot fi,
de asemenea, modificate prin opțiunile anonuid și anongid. În cele din urmă, puteți asocia toate cererile
utilizatorilor cu uid-ul anonim specificând opțiunea all_squash.
Iată lista completă a opțiunilor de corespondență:
root_squash
Asociază cererile de la uid/gid 0 la uid/gid anonim. Rețineți că acest lucru nu se aplică oricăror
alte uid-uri sau gid-uri care ar putea fi la fel de sensibile, cum ar fi utilizatorul bin sau
grupul staff.
no_root_squash
Dezactivează asocierea cererilor de la uid/gid 0 la uid/gid anonim. Această opțiune este utilă în
principal pentru clienții fără disc.
all_squash
Asociază toate uid-urile și gid-urile cu utilizatorul anonim. Utilă pentru directoarele FTP
publice exportate NFS, directoarele spool de știri etc. Opțiunea opusă este no_all_squash, care
este opțiunea implicită.
anonuid și anongid
Aceste opțiuni stabilesc în mod explicit uid-ul și gid-ul contului anonim. Această opțiune este
utilă în primul rând pentru clienții PC/NFS, unde s-ar putea să doriți ca toate cererile să pară a
fi de la un singur utilizator. Ca exemplu, luați în considerare intrarea de export pentru
/home/joe din secțiunea de exemplu de mai jos, care asociază toate cererile cu uid 150 (care se
presupune că este cel al utilizatorului joe).
Exporturi de subdirectoare
În mod normal, ar trebui să exportați doar rădăcina unui sistem de fișiere. Serverul NFS vă va permite,
de asemenea, să exportați un subdirector al unui sistem de fișiere, însă acest lucru are dezavantaje:
În primul rând, poate fi posibil ca un utilizator rău intenționat să acceseze fișiere din sistemul de
fișiere din afara subdirectorului exportat, prin ghicirea gestionarilor de fișiere pentru aceste alte
fișiere. În unele cazuri, un utilizator rău intenționat poate, de asemenea, să acceseze fișiere de pe
alte sisteme de fișiere care nu au fost exportate prin înlocuirea subdirectorului exportat cu o legătură
simbolică către orice alt director. Singurul mod de a preveni acest lucru este prin utilizarea opțiunii
subtree_check, care poate cauza alte probleme.
În al doilea rând, este posibil ca opțiunile de export să nu fie puse în aplicare în modul în care v-ați
aștepta. De exemplu, opțiunea security_label nu va funcționa la exporturile de subdirectoare, iar dacă
exporturile de subdirectoare imbricate modifică opțiunile security_label sau sec=, clienții NFSv4 vor
vedea în mod normal numai opțiunile de pe exportul părinte. De asemenea, atunci când opțiunile de
securitate diferă, un client rău intenționat poate utiliza atacuri de tip „filehandle-guessing” pentru a
accesa fișierele dintr-un subdirector, utilizând opțiunile din altul.
Tabele de export suplimentare
După citirea fișierului /etc/exports exportfs citește fișierele din directorul /etc/exports.d ca tabele
de export suplimentare. Sunt luate în considerare numai fișierele care se termină în .exports. Fișierele
care încep cu un punct sunt ignorate. Formatul pentru tabelele de export suplimentare este același ca în
cazul fișierului /etc/exports
EXEMPLU
# fișier „/etc/exports” de exemplu
/ master(rw) trusty(rw,no_root_squash)
/projects proj*.local.domain(rw)
/usr *.local.domain(ro) @trusted(rw)
/home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
/pub *(ro,insecure,all_squash)
/srv/www -sync,rw server @trusted @external(ro)
/foo 2001:db8:9:e54::/64(rw) 192.0.2.0/24(rw)
/build buildhost[0-9].local.domain(rw)
Prima linie exportă întregul sistem de fișiere către mașinile master și trusty. În plus față de accesul
la scriere, pentru gazda trusty se dezactivează toate operațiile de asociere a cererilor de la uid/gid 0
la uid/gid anonim A doua și a treia intrare prezintă exemple de nume de gazdă și grupuri de rețele cu
caractere joker (aceasta este intrarea „@trusted”). A patra linie prezintă intrarea pentru clientul
PC/NFS discutat mai sus. Linia 5 exportă directorul FTP public către toate gazdele din lume, executând
toate cererile sub contul nobody. Opțiunea insecure din această intrare permite, de asemenea, accesul
clienților cu implementări NFS care nu utilizează un port rezervat pentru NFS. A șasea linie exportă un
director în citire-scriere către mașina „server”, precum și către grupul de rețea „@trusted” și numai în
citire către grupul de rețea „@external”, toate cele trei montări având activată opțiunea „sync”. A
șaptea linie exportă un director atât către o subrețea IPv6, cât și către o subrețea IPv4. A opta linie
demonstrează o potrivire a unui caracter joker de clasă.
FIȘIERE
/etc/exports /etc/exports.d
CONSULTAȚI ȘI
exportfs(8), netgroup(5), mountd(8), nfsd(8), showmount(8), tlshd(8).
TRADUCERE
Traducerea în limba română a acestui manual a fost făcută de Remus-Gabriel Chelu
<remusgabriel.chelu@disroot.org>
Această traducere este documentație gratuită; citiți Licența publică generală GNU Versiunea 3 sau o
versiune ulterioară cu privire la condiții privind drepturile de autor. NU se asumă NICIO
RESPONSABILITATE.
Dacă găsiți erori în traducerea acestui manual, vă rugăm să trimiteți un e-mail la translation-team-
ro@lists.sourceforge.net.
31 decembrie 2009 exports(5)