Nfs-kernel-server: condividere risorse tra macchine GNU/Linux

File System e dispositivi fisici

Generalità File System Udev Locali LVM: Logical Volume Manager RAID: Redundant Array of Indipendent Disks Remoti NFS Samba SSHFS Strumenti fdisk GNU Parted

Attenzione. Questa guida è da considerarsi abbandonata, per via del tempo trascorso dall'ultima verifica. Potrà essere resa obsoleta, previa segnalazione sul forum, se nessuno si propone per l'adozione.

Versioni Compatibili Debian 5 "lenny" Debian 6 "squeeze" Debian 7 "wheezy" Debian 8 "jessie"

NFS

Sommario

Spazio Kernel Principale NFS V2-V3 NFS V4 Lato server Lato client Diagnostica e prestazioni Approfondimenti Client Windows Esempi

Introduzione

NFS è l'acronimo di Network Filesystem, ovvero un filesystem utilizzato per montare cartelle remote sul proprio filesystem locale (o meglio per condividere in una LAN filesystem presenti su un server). L'utente in sintesi mette a disposizione una o più risorse (ovvero una directory del proprio filesystem) presenti su una delle sue macchine e le altre vi possono accedere come fosse una directory del proprio filesystem. In poche parole NFS permette di impostare un sistema di condivisioni simili a quello di Windows, o meglio, è Windows che ha "copiato" NFS per realizzare il suo sistema di condivisione.

NOTE L'utilizzo di NFS è consigliato solo all'interno di una LAN, in caso contrario è preferibile ricorrere ad altre soluzioni come SSHFS. Sebbene NFS sia privilegiato in ambienti UNIX puri è comunque possibile sfruttarlo anche in ambienti misti con client Windows.

Al di là di quest'aspetto 'estetico' il vantaggio principale consiste nel poter accedere alle risorse remote come se fossero risorse locali, cosa non possibile se si utilizzano protocolli come FTP/SFTP o HTTP (che sono alcuni dei protocolli sfruttati dalla funzione "Risorse --> Connetti al server" di GNOME). In sintesi è possibile manipolare file e directory sfruttando tutte le possibilità che un normale filesystem offre.
A titolo d'esempio si cita la condivisione di calendari in Thunderbird; come noto è impossibile condividere un calendario e/o una rubrica tramite protocollo SFTP, mentre risulta possibile usando FTP/HTTP anche se l'operazione risulta macchinosa ed in ogni caso le credenziali sono trasmesse in chiaro. Usando NFS invece l'operazione non presenta differenze rispetto al caso in cui il calendario fosse stato salvato in una posizione realmente presente sul disco rigido della propria macchina.

Versioni

Da Wikipedia:

Network File System (NFS) è un protocollo sviluppato inizialmente da Sun Microsystems nel 1984 e definito dagli RFC 1094, 1813, (3010) e 3530.

In questi trent'anni il protocollo NFS è stato migliorato più volte attraverso la definizione di nuovi versioni, pertanto trascurando quelle più vecchie ormai completamente obsolete, ci si limiterà alla versione 3 (1995) e alla versione 4 (2000).
Per completezza si segnala che da qualche anno è in sviluppo la versione 4.1 del protocollo.

Importante

• Dal punto di vista della configurazione non esistono differenze tra le versioni 2 e 3, mentre la versione 4 introduce alcune piccole differenze di sintassi.
• La scelta del protocollo da utilizzare avviene lato client e non lato server, ovvero attraverso mount e quindi tutti gli strumenti che da esso dipendono (/etc/fstab, autofs, ecc.). A meno che l'utente non specifichi esplicitamente il protocollo da usare tramite l'opzione nfsvers (o l'equivalente vers) avverrà una negoziazione per tentativi tra client e server partendo dalla versione 4; in caso di fallimento verrà provata la versione 3, dopo di che, se anche questa fallisce, procede automaticamente con un ultimo tentativo usando la versione 2 del protocollo.
• È possibile restringere lato server le versioni utilizzabili del protocollo editando opportunamente il parametro RPCMOUNTDOPTS del file /etc/default/nfs-kernel-server. Richieste di utilizzo di versioni bloccate del protocollo da parte dei client vengono negate.

Sicurezza

Nel caso di una piccola rete domestica/aziendale il discorso sicurezza lascia il tempo che trova, dato che di norma in questi casi hanno accesso alle macchine solo persone fidate. Se però così non fosse è bene essere consapevoli che la condivisione NFS non abbinata ad un sistema di autenticazione centralizzato, come kerberos o ldap, è causa di gravi vulnerabilità.

Con i vari protocolli di rete come FTP, SFTP, ecc. è infatti necessario effettuare un'autenticazione presso il server ospitante le risorse (che poi queste credenziali siano trasmesse in chiaro o cifrate è un altro paio di maniche), mentre con NFS non viene fatta alcuna autenticazione "diretta". Una volta definite le risorse da esportare l'accesso a queste è regolato solo in base all'UID dell'utente (V3 e precedenti), oppure in base all'UID per quanto riguarda i permessi tipo unix e in base al nome utente per quanto riguarda regole ACL e determinazione del proprietario (da V4, citazione); poiché gli UID degli utenti di base sono assegnati in modo crescente a partire da uno stesso numero (cioè 1000, almeno per Debian e derivati), a meno che un utente non decida di cambiarli sua sponte, è evidente come l'accesso alle stesse sia tutt'altro che sicuro.
In realtà è possibile restringere l'accesso alle stesse in base all'indirizzo IP (in Lenny man portmap, man exports per tutti), tuttavia questo accorgimento potrebbe non essere adeguato e/o sufficiente.
Poiché su ogni macchina almeno un utente deve esistere, è chiaro per quanto detto che tutte le macchine hanno almeno un utente con lo stesso UID (a meno di modifiche fatte appositamente), cioè quello creato in fase d'installazione.
Il risultato è che i vari utenti della rete potrebbero avere accesso a risorse cui non dovrebbero o che comunque non gli interessano, oppure non avere accesso alle risorse che gli servono, ecc. Basta infatti che l'UID dell'utente con cui ci si è autenticati sul computer 'A' coincida con uno di quelli associati ai nomi_utente del PC 'B'.

Esempio: due utenti possiedono entrambi due computer con sistema GNU/Linux e decidono di mettere in rete le rispettive macchine per condividere alcune cartelle. L'utente 'A', che possiede il computer 'A', durante l'installazione di Linux ha scelto come nome_utente 'tizio', mentre l'utente B proprietario del computer 'B' ha scelto come nome utente 'caio'. Di norma perché l'utente 'A' possa accedere alle risorse su 'B' è necessario che l'utente 'B' crei un utenza apposita sul PC 'B' e che poi comunichi nome utente e password all'utente 'A'.
Col filesystem NFS il controllo dell'accesso alle varie risorse non viene fatto su una coppia di credenziali "nome_utente+password", ma solo sugli UID degli utenti; poiché sia 'tizio' che 'caio' sono stati i primi utenti creati rispettivamente sui PC 'A' e 'B' è evidente che dovranno avere anche lo stesso UID, avendo già detto che Linux associa di base UID=1000 al primo utente creato. Il risultato finale nella migliore delle ipotesi è che l'utente 'A' acceda alle sole risorse scelte da 'B' con i privilegi di 'B' invece che di 'A' (cioè quelli attribuiti da 'B' ad 'A') e viceversa. Nel peggiore dei casi, poiché quando si condivide una cartella vengono automaticamente condivise tutte le sotto cartelle, l'utente 'A' avrà accesso con i privilegi di 'B' (e viceversa) a cartelle cui normalmente non avrebbe dovuto avere accesso, il che può essere più o meno grave a seconda della sensibilità dei dati in esse contenute.

Come già detto inizialmente questo problema è normalmente puramente teorico, poiché nella maggior parte delle piccole LAN private l'accesso alla rete ed ai PC che la compongono è possibile solo a persone di fiducia e/o in ogni caso le risorse condivise non contengono dati particolarmente sensibili. Se però così non fosse, l'utente sarebbe costretto ad implementare o un sistema di autenticazione come kerberos/ldap oppure a RINUNCIARE all'uso di NFS.

Si noti che se su un computer non sono presenti un'utenza ed un gruppo aventi il medesimo nome di quelli presenti sulla macchina che esporta le risorse, allora visualizzando le proprietà di file e cartelle attraverso Nautilus sulla macchina client verranno indicati come proprietario e gruppo nouser e nogroup. Accedendo invece dal server alle medesime risorse i nomi di proprietario e gruppo risulteranno corretti anche per file e cartelle creati dall'utente remoto.

Ultime note

Per navigare attraverso le pagine della guida usare il menù laterale. Si tenga presente che non è necessario leggersi tutte le pagine, in particolare la guida per lo "Spazio User" è ormai obsoleta in quanto facente riferimento ad un pacchetto non più disponibile da Squeeze; anche qualora l'utente usasse ancora Lenny è invitato ad usare l'applicativo che lavora a livello di kernel ("Spazio Kernel").
Similmente se si decidesse di usare la versione 3 del protocollo non sarebbe strettamente necessario leggersi le pagine relative alla 4, tuttavia si tenga presente che la sezione relativa al troubleshooting di quest'ultima è probabilmente valida in molti punti anche per la versione 3.

---

Guida scritta da: xtow	Debianized 60%
Estesa da: Wtf 17:13, 5 giu 2011 (CEST)
Verificata da: Wtf, eccetto V2-V3 Mirko.pagliai 19:31, 19 mar 2012 (CET), eccetto "metodo dinamico"
Verificare ed estendere la guida | Cos'è una guida Debianized