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

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
Nessun oggetto della modifica
Riga 37: Riga 37:
: [[Utente:Wtf|Wtf]] 17:13, 5 giu 2011 (CEST)
: [[Utente:Wtf|Wtf]] 17:13, 5 giu 2011 (CEST)
|Verificata_da =
|Verificata_da =
: [[Utente:Wtf|Wtf]]
: [[Utente:Wtf|Wtf]], eccetto Lenny
: [[Utente:Mirko.pagliai|Mirko.pagliai]] 19:31, 19 mar 2012 (CET), eccetto "metodo dinamico"
: [[Utente:Mirko.pagliai|Mirko.pagliai]] 19:31, 19 mar 2012 (CET), eccetto "metodo dinamico"
| Numero_revisori = 2
| Numero_revisori = 2

Versione delle 08:51, 29 mar 2012

File System e dispositivi fisici

Generalità

Locali

Remoti

Strumenti


Edit-clear-history.png 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.


Debian-swirl.png Versioni Compatibili

Debian 5 "lenny"
Debian 6 "squeeze"
Debian 7 "wheezy"
NFS

Sommario

Spazio Kernel
  1. Lato server
  2. Lato client


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 file system) presenti su una delle sue macchine e le altre vi possono accedere come fosse una directory del proprio file system. 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.

Info.png NOTA
L'utilizzo di NFS è consigliato solo all'interno di una LAN, in caso contrario è preferibile ricorrere ad altre soluzioni come SSHFS.


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 file system offre. A titolo d'esempio si cita la condivisione di calendari in Thunderbird; come noto è impossibile condvidere 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.

Sia chiaro che ogni macchina può simultaneamente condividere alcune risorse che accedere a quelle presenti su altre macchine.

Nel seguito si vedrà come configurare sia la macchina che condivide le risorse (server) sia quelle che dovranno accedervi (client), tuttavia risulta opportuno esporre prima alcune considerazioni sulla sicurezza.

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 in base all'UID dell'utente; 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 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 contegono 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.




Guida scritta da:
xtow
Swirl-auth60.png Debianized 60%
Estesa da:
Wtf 17:13, 5 giu 2011 (CEST)
Verificata da:
Wtf, eccetto Lenny
Mirko.pagliai 19:31, 19 mar 2012 (CET), eccetto "metodo dinamico"

Verificare ed estendere la guida | Cos'è una guida Debianized