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.