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

nessun oggetto della modifica
Nessun oggetto della modifica
Nessun oggetto della modifica
Riga 14: Riga 14:


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à.
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, per quanto in realtà sia possibile restringere l'accesso alle stesse in base all'indirizzo IP (accorgimento comunque non impossibile da aggirare).
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, per quanto in realtà sia possibile restringere l'accesso alle stesse in base all'indirizzo IP (accorgimento comunque non impossibile da aggirare).
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 e contemporaneamente non avere accesso alle risorse che gli servono. Basta infatti che l'UID del nome_utente con cui ci si è autenticati sul PC 'A' coincida con uno di quelli associati ai nomi_utente del PC 'B'.
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 e contemporaneamente non avere accesso alle risorse che gli servono. Basta infatti che l'UID del nome_utente con cui ci si è autenticati sul PC 'A' coincida con uno di quelli associati ai nomi_utente del PC 'B'.
Esempio: due utenti possiedono entrambi un PC 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' riveli la sua password ad 'A' in modo che 'A' possa creare sulla macchina 'A' un utente 'caio' grazie al quale accedere al PC 'B', oppure che l'utente 'B' crei un utente 'tizio' sul PC 'B' e che poi comunichi la relativa password all'utente 'A'.
 
''Esempio'': due utenti possiedono entrambi un PC 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' riveli la sua password ad 'A' in modo che 'A' possa creare sulla macchina 'A' un utente 'caio' grazie al quale accedere al PC 'B', oppure che l'utente 'B' crei un utente 'tizio' sul PC 'B' e che poi comunichi la relativa 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, poiché come già detto 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.
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, poiché come già detto 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.  
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.  


Riga 86: Riga 89:
<pre># /etc/init.d/nfs-kernel-server restart</pre>
<pre># /etc/init.d/nfs-kernel-server restart</pre>


===== Rimontare le directory =====
È possibile rimontare una o più cartelle in una seconda posizione col risultato che il contenuto delle cartelle risulta accessibile da due differenti posizioni (quella originale e quella dove si rimonta). Per far ciò è prima necessario creare il punto di mount, per esempio:
<pre>
# mkdir -p /export/utente
# mkdir -p /export/altro
</pre>
Supponendo di voler rimontare le cartelle <code>/home/utente</code> e <code>/altro</code> rispettivamente in <code>/export/utente</code> e <code>/export/altro</code>:
<pre>
# mount --bind /home/utente /export/utente
# mount --bind /var/www /export/www
</pre>
Per evitare di dover ridigitare ad ogni riavvio i precedenti comandi basta aggiungere le seguenti due righe al file <code>/etc/fstab</code>:
<pre>
/home/utente /export/utente none bind 0 0
/var/www /export/www none bind 0 0
</pre>
A questo punto per esportare la cartella <code>/export</code> non rimane che editare il file <code>etc/exports</code>
<pre>
/export 192.168.1.0/24(rw,fsid=0,no_subtree_check,sync)
/export/utente 192.168.1.0/24(rw,no_subtree_check,sync,nohide)
/export/www 192.168.1.0/24(rw,no_subtree_check,sync,nohide)
</pre>
Da notare l'aggiunta dell'opzione <code>nohide</code>, che non deve essere omessa pena l'impossibilità di vedere il contenuto delle sottocartelle di ''export'' sulle macchine client. Quest'opzione risulta utile proprio in questo tipo di situazione specifica, ovvero dove alcune cartelle vengono "rimontate" in una seconda posizione (l'opzione crossmnt ha un effetto molto simile a nohide). In caso di problemi a visualizzare il contenuto delle cartelle provare a riavviare server e client.


== Impostazioni lato client ==
== Impostazioni lato client ==
Riga 125: Riga 160:
# mount -a</pre>
# mount -a</pre>


=== Esempio 2 ===
==== Esempio 2 ====


Sia che si voglia caricare le risorse remote in modo statico che dinamico, La prima cosa da fare è assicurarsi che sul PC client sia installato il pacchetto nfs-common, in caso contrario installarlo.
Sia che si voglia caricare le risorse remote in modo statico che dinamico, La prima cosa da fare è assicurarsi che sul PC client sia installato il pacchetto nfs-common, in caso contrario installarlo.
Riga 197: Riga 232:
Fatto ciò le risorse risulteranno visibile anche in nautilus.
Fatto ciò le risorse risulteranno visibile anche in nautilus.


== Conclusioni ==
== Possibili Problemi ==
Come scritto all'inizio questo è il modo più semplice per condividere risorse tra macchine GNU/Linux; queste impostazioni sono adatte ad una rete privata, dove non ci sono problemi di sicurezza, visto che ho lasciato abilitato la condivisione a tutta la LAN. Se si vuole fare una condivisione più mirata o selettiva
 
<pre>man nfs</pre>
Tra i problemi tipici cquello di non riuscire a montare le risorse remote. Una prima verifica banale è quella di assicurarsi che la cartella dove devono essere montate le risorse remote sia indicata correttamente (per esempio <code>/home/nfs</code> è DIVERSO da <code>/home/NFS</code>). Una seconda causa potrebbe essere dovuta al numero della porta che NFS sceglie casualmente, infatti se il numero della porta è maggiore di 1024 scatta un errore di sicurezza; in tal caso è sufficiente aggiungere alle opzioni indicate nel file <code>/etc/exports</code> anche insecure, ad esempio:
e
 
<pre>man portmap</pre>
<pre>
/home 192.168.1.0/24(rw,fsid=0,no_subtree_check,sync,insecure)
/home/altro 192.168.1.0/24(rw,no_subtree_check,sync,insecure)
</pre>
 
Un altro motivo potrebbe essere costituito dal set di permessi delle cartelle esportate; provare ad impostare temporaneamente i loro permessi su 777. Se il problema è risolto provare a reimpostare i permessi sul vecchio schema e vedere se l'errore si ripropone.
Potrebbe capitare che trasferendo grossi file il server si congeli obbligando ad un riavvio forzato, in tal caso potrebbe essere utile specificare le opzioni rsize e wsize indicando valori non troppo grandi, per esempio:
 
* Caso statico: <pre>mount -t nfs4 -o rsize=8192,wsize=8192 indirizzo_server:/ /home/nfs</code>
 
* Caso statico, file <code>/etc/fstab</code> aggiungere (o modificare quella già esistente): <code>indirizzo_server:/ /home/NFS nfs4 _netdev,auto,rsize=8192,wsize=8192 0 0</code>
 
* Caso dinamico, file <code>/etc/auto.nfs</code> aggiungere (o modificare quella già esistente) <pre>nome_arbitrario -fstype=nfs4,rsize=8192,wsize=8192 indirizzo_server:/</code>
 
A tal proposito potrebbe essere utile leggere [http://nfs.sourceforge.net/nfs-howto/ar01s07.html#cpu_cycles_nfs questo].
Nel caso di ''autofs'' se il server è spento e sulla macchina client è presente un collegamento simbolico alle risorse esterne, creato per esempio con un comando del tipo:
 
<pre># ln -s /home/nfs/nome_arbitrario /home/nome_utente/nome_arbitrario</code>
 
è probabile che si noti un ritardo di circa 3 minuti all'avvio di gnome ed ogni volta che si lancia nautilus per visualizzare una qualche cartella. La semplice presenza del collegamento simbolico è infatti sufficiente ad innescare una richiesta di caricamento per le risorse remote, con la conseguenza che essendo il server spento queste falliscano inevitabilmente. Di base autofs è impostato per ripetere la richiesta di caricamento risorse dopo 60s per un massimo di 3 volte, ecco dunque da dove nascerebbero i 3 minuti di ritardo sistematico. In tal caso la soluzione più semplice è rinunciare ai collegamenti simbolici verso le risorse remote caricate tramite nfs, altrimenti è possibile ridurre i valori delle variabili <code>timeo</code> e <code>retrans</code> specificandoli nel file <code>/etc/auto.nfs</code> (o come è stato chiamato):
 
<pre>nome_arbitrario -fstype=nfs4,timeo=150,retrans=2 indirizzo_server:/</pre>
 
In questo esempio il tempo di timeout viene ridotto a 150 decimi di secondo (15s) ed il numero di tentativi ridotto a 2, così che ogni volta il ritardo sia di "soli" 15x2=30s.
Altre problematiche sono descritte al punto 7 di [http://nfs.sourceforge.net/nfs-howto/ questa pagina].
 
== Riferimenti esterni ==
 
Manuali:
<code>man nfs</code>
<code>man portmap</code>
 
Pagine web:
 
* [http://nfs.sourceforge.net/ Sourceforge], pagina ufficiale.
* [https://wiki.linux-nfs.org/wiki/index.php/Main_Page linux-nfs].
* [http://www.linux-tutorial.info/modules.php?name=MContent&pageid=150 linux-tutorial].
 
::::::::::::::::::::::::::::::::::::::::::::::
::::::::::::::::::::::::::::::::::::::::::::::
[[Utente:xtow|xtow]]
[[Utente:xtow|xtow]]
 
--[[Utente:Wtf|Wtf]] 17:13, 5 giu 2011 (CEST)




[[Categoria:Condivisione_risorse]]
[[Categoria:Condivisione_risorse]]
[[Categoria:NFS]]
[[Categoria:NFS]]
2 894

contributi