Provided by:
manpages-it_0.3.4-5_all 
NOME
exports - file system NFS che sono esportati
SINTASSI
/etc/exports
DESCRIZIONE
Il file /etc/exports fa da elenco per il controllo dell’accesso per
file system che possono essere esportati a clienti NFS. È usato sia dal
demone per il mount NFS, mountd(8) che dal demone di file server NFS
nfsd(8).
Il formato del file è simile a quello del file exports di SunOS, tranne
per il fatto che sono permesse diverse opzioni addizionali. Ogni riga
contiene un mount point e una lista di macchine o gruppi di rete
(netgroup) autorizzati a montare il file system in quel posto. Ogni
nome di macchina può essere seguito da una lista opzionale, tra
parentesi, di parametri per mount. Le righe vuote sono ignorate, e un #
introduce un commento fino alla fine della riga. Le voci possono essere
continuate su più righe usando un backslash.
Formato dei nomi delle macchine
I clienti NFS possono essere specificati in più modi:
single host
Questo è il formato più comune: un nodo può essere indicato sia
da un nome abbreviato riconosciuto dal resolver, da un nome di
dominio completamente qualificato (fqdn) oppure da un indirizzo
IP.
gruppi di reti
I gruppi NIS possono essere dati come @group: Solo la parte di
nodo di ogni mebro del gruppo viene estratta ed aggiunta alla
lista d’acceso. Parti di nodo vuote o contenenti solo un
trattino «-» sono ignorate.
metacaratteri
I nomi delle macchine possono conteneri i metacaratteri * e ?:
ciò può essere usare per rendere più compatto il file exports;
per esempio, *.cs.foo.edu corrisponde a tutti i nodi nel dominio
cs.foo.edu. Questi metacaratteri, però, non corrispondono ai
punti del nome del dominio, per cui il modello di prima non
corrisponderebbe a a.b.cs.foo.edu.
reti IP
È anche possibile esportare directory contemporaneamente verso
tutti i nodi di una (sotto-)rete IP: lo si fa specificando una
coppia indirizzo IP e netmask come indirizzo/netmask.
=public
Questo è un nome speciale che indica la directory data come la
directory radice publica (vedi la sezione WebNFS di nfsd(8) per
una discussione su WebNFS e la gestione della radice pubblica).
Usando questa convenzione, =public deve essere l’unica opzione
della riga e nessuna opzione d’esportazione gli può essere
associata. Si noti che in realtà questo non esporta la directory
citata: bisogna ancora dare le opzioni d’esportazione in una
voce separata.
Il percorso della radice pubblica può essere specificato anche
invocando nfsd con l’opzione --public-root. Specifiche ripetute della
radice pubblica vengono ignorate.
Opzioni Generali
mountd e nfsd comprendono le seguenti opzioni d’esportazione:
secure Questa opzione richiede che la richiesta sia originata da una
porta internet con numero minore di IPPORT_RESERVED (1024).
Questa opzione è abilitata di natura. Per disabilitarla,
specificare insecure.
ro Permette solo richieste di sola lettura su questo volume NFS. Il
comportamento predefinito è di permettere anche richieste di
scrittura, cosa che può essere anche specificata esplicitamente
usando l’opzione rw.
noaccess
Rende tutto ciò che sta sotto alla directory inacessibile al
cliente in questione: molto utile quando si vuole esportare una
gerarchia di directory verso un cliente, ma escludendo certe
sottodirectory. Il cliente ha una visione molto ristretta di una
directory marcata con noaccess: può leggerne gli attributi e
vedere «.» e «..»; queste sono anche le uniche voce riportate da
una readdir.
link_relative
Converte collegamenti simbolici assoluti (quelli in cui il
contenuto del collegamento inizia con uno slash «/») in
collegamenti relativi precedendoli con il numero di ../
necessario per portarli dalla directory che contiene il link
alla radice del server. Ciò ha una sottile, forse discutibile,
semantica quando la gerarchia dei file non è montata nella
propria radice.
link_absolute
Lascia stare tutti i collegamenti. Questa è l’operazione
predefinita.
Correlazione degli identificativi utente
nfsd basa il suo controllo d’accesso ai file del server sull’uid e il
gid forniti in ognuna delle richieste RPC di NFS. Il comportamento
normale che un utente si aspetterebbe è di poter accedere a sui file
nel server proprio come farebbe in un normale file system. Ciò richiede
che siano usati gli stessi uid e i gid sul cliente e sul server. Ciò
non sempre è vero, per quanto sia sempre preferibile.
Molto spesso, non è desiderabile che l’utente root del cliente sia
trattato come root anche quando accede ai file nel server NFS. A questo
scopo, l’uid 0 è normalmente trasformato in un identificativo
differente: il cosiddetto uid anonimo (anonymous) o nobody (nessuno).
Questo è il modo di operare (detto «root squashing»=«schiacciamento di
root») predefinito, e può essere disabilitato con no_root_squash.
Di default, nfsd prova a ottenere l’uid e il gid anonimi ricercando
all’avvio l’utente nobody nel file delle password. Se non lo trova,
sono allora usati un uid e un gid pari a -2 (cioè 65534). Questi valori
possono essere ridefiniti dalle opzioni anonuid e anongid.
Oltre a questo, nfsd permette comunque di specificare gli uid e i gid
ai quali dovrebbe corrispondere l’utente nobody. Inoltre si possono
mappare tutte le richieste degli utenti all’uid anonimo specificando
l’opzione all_squash.
A beneficio delle installazioni in cui gli uid differiscono tra
macchine diverse, nfsd fornisce più metodi per correlare dinamicamente
gli uid del server con gli uid del cliente e viceversa: file di
correlazione statica, correlazione basata su NIS e correlazione basata
su ugidd.
La correlazione basata su ugidd è avviata dall’opzione map_daemon, ed
usa il protocollo RPC UGID. Perché funzioni, si deve avviare nel
cliente il demone di correlazione ugidd(8). Questo è il meno sicuro
dei tre metodi, poiché grazie a ugidd ognuno può richiedere al cliente
un elenco dei nomi utente validi. Ci si può proteggere da questo
rischio restringendo l’accesso a ugidd ai soli nodi validi: basta
inserire l’elenco dei nodi validi in hosts.allow o (quelli invalidi) in
hosts.deny; il nome del servizio è ugidd. Si veda hosts_access (5) per
una descrizione della sintassi dei questi file.
La correlazione statica si attiva con l’opzione map_static, che prende
come argomento il nome di un file che descrive la correlazione. La
correlazione basata su NIS richiede al server NIS del cliente di
mettere in relazione i nomi utente e gruppo sul server con quelli sul
cliente.
Ecco qui una lista completa delle opzioni di correlazione:
root_squash
Trasforma le richieste dell’uid/gid 0 nel’uid/gid anonimo. Si
noti che ciò non è applicato a ogni altro uid che potrebbe
essere ugualmente sensibile, come l’utente bin.
no_root_squash
Disabilita il root squashing. Questa opzione è utile
principalmente per clienti senza disco (diskless).
squash_uids e squash_gids
Questa opzione specifica un elenco di uid e gid che dovrebbero
essere trasformati in anonimo. Un’elenco valido di uid è come
questo:
squash_uids=0-15,20,25-50
Solitamente la propria lista di squash sarà molto più semplice.
all_squash
Trasforma tutti gli uid e i gid nell’utente anonimo. Utile per
directory FTP pubbliche esportate in NFS, directory di spool
delle news, ecc. L’opzione opposta è no_all_squash, che è
l’impostazione predefinita.
map_daemon
Questa opzione abilita la correlazione dinamica di uid/gid. Ogni
uid in una richiesta NFS sarà tradotto nell’equivalente uid nel
server, e ogni uid in una risposta NFS sarà trasformato nel modo
opposto. Questa opzione richiede che rpc.ugidd(8) giri nel
cliente. L’impostazione predefinita è map_identity, che lascia
invariati tutti gli uid. Le normali opzioni di squash si
applicano indipendentemente dall’attivazione della correlazione
dinamica.
map_static
Questa opzione abilita la correlazione statica: specifica un
file che descrive le trasformazioni di uid e gid. Ad esempio,
map_static=/etc/nfs/foobar.map
Il formato del file ha questo aspetto:
# Correlazioni per il cliente pippo:
# remoto locale
uid 0-99 - # schiscia questi
uid 100-500 1000 # trasforma 100-500 in 1000-1500
gid 0-49 - # schiscia questi
gid 50-100 700 # trasforma 50-100 in 700-750
map_nis
Questa opzione abilita la correlazione basata su NIS. Per
esempio, se il server s’imbatte nello uid 123, considera il nome
utente associato e contatta il server NIS del cliente NFS per
ottenere lo uid associato a quel nome sul cliente.
Per fare ciò, il server NFS deve conoscere il dominio NIS del
cliente: lo si specifichi come argomento all’opzione map_nis;
per esempio,
map_nis=pippo.com
Si noti che indicare qui il dominio NIS potrebbe non bastare:
ulteriori azioni potrebbero essere necessarie prima che nfsd
possa entrare in contatto col server. Se la propria
distribuzione utilizza la libreria NYS, uno o più server NIS per
il dominio del cliente possono essere specificati in
/etc/yp.conf. Se è in uso un’altra libreria NIS, potrebbe
essere necessario ottenere un demone ypbind(8) speciale da
configurare tramite yp.conf.
anonuid e anongid
Queste opzioni impostano esplicitamente l’uid e il gid
dell’account anonimo. Sono utili principalmente per clienti
PC/NFS, dove si potrebbe volere che tutte le richieste appaiano
provenire da un unico utente. Per esempio, si consideri la voce
per esportare /home/vasco nella sottostante sezione ESEMPIO, che
trasforma tutte le richieste all’uid 150 (che si suppone essere
quello dell’utente vasco).
ESEMPIO
# campione di /etc/exports
/ capo(rw) fiducioso(rw,no_root_squash)
/progetti prog*.dominio.locale(rw)
/usr *.dominio.locale(ro) @fiducioso(rw)
/home/vasco pc001(rw,all_squash,anonuid=150,anongid=100)
/pub (ro,insecure,all_squash)
/pub/privato (noaccess)
La prima riga esporta l’intero filesystem alle macchine capo e
fiducioso. In aggiunta all’accesso in scrittura, è disabilitato l’uid
squashing per fiducioso. La seconda e terza voce mostrano esempi di
metacaratteri per nomi di nodi e gruppi (la voce ‘@fiducioso). La
quarta riga mostra la voce per un cliente PC/NFS di cui si è parlato
prima. La quinta riga esporta la directory FTP pubblica ad ogni nodo
sul pianeta, eseguendo tutte le richieste sotto l’account nobody.
L’opzione insecure in questa voce permette anche clienti il cui NFS non
usi la porta riservata per NFS. L’ultima riga nega l’accesso alla
directory privata a tutti i clienti NFS.
AVVERTENZE
Diversamente da altre implementazioni del server NFS, questo nfsd
permette di esportare verso lo stesso nodo una directory ed una sua
sottodirectory, per esempio /usr e /usr/X11R6. In questo caso, sono
applicate le opzioni di mount della voce più specifica. Per esempio,
quando un utente accede nel cliente ad un file in /usr/X11R6, sono
applicate le opzioni di mount date nella voce relativa a /usr/X11R6.
Questo vale anche quando quest’ultima è data da un metacarattere o un
gruppo di rete.
FILE
/etc/exports
DIAGNOSTICA
Ogni errore nell’analisi del file, riscontrato durante l’avvio di
nfsd(8) oppure mountd(8), viene segnalato tramite syslogd(8) al livello
NOTICE in provenienza da un DEMONE. Qualsiasi nodo sconosciuto è
segnalato in questo momento, ma spesso non tutti i nodi sono già noti a
named(8) al momento dell’avvio, quindi vengono segnalati, con gli
stessi parametri di syslogd(8), non appena trovati.
VEDERE ANCHE
mountd(8), nfsd(8)