Ho provato questa procedura su Kubuntu 14.04 e 14.10 ma cerdo valga per qualsiasi configurazione/versione di Ubuntu.
Siccome è una situazione un po' particolare e poco utile, se non per qualche test o poche altre funzioni, se qualcuno ha qualche informazione più precisa/corretta di quelle che riporterò io, sarà ben accetta. Grazie.
Veniamo al dunque...
La mia situazione è la seguente:
- Server LAMP installato
- Modificato i file di configurazione per operare sotto la directory /home/nome-utente/www
- /home in una partizione separata (ma non è importante, giusto per precisare)
La mia necessità invece è questa:
Devo poter accedere a dei file all'esterno della directory di lavoro, più precisamente il secondo disco, con file system di tipo NTFS, senza ricevere ovviamente un errore 403 di accesso negato.
Ora descriverò la soluzione raggiunta da me.
Innanzitutto ecco un po' di guide a cui mi sono appoggiato:
- Manuale NTFS-3G
- Documentazione wiki di Ubuntu, montare partizioni NTFS
- Documentazione wiki di Ubuntu, Fstab
- Help ufficiale di Ubuntu, Fstab
- Man Page di NTFS-3G
In pratica bisogna fare trovare sempre pronta (ossia montata) la partizione NTFS in questione, inoltre Apache deve potervi accedere quindi bisogna sistemare anche i permessi.
Per montare all'avvio la partizione NTFS desiderata, ho inserito la seguente riga nel file /etc/fstab
UUID=D0588B05588AEA14 /media/DATI ntfs-3g nodiratime,noatime,defaults,uid=1000,gid=1000,locale=it_IT.utf8,dmask=027,fmask=137 0 0
Per trovare l'UUID (Universally Unified Identifier) del disco basta dare il comando
blkid
Verrà restituito l'elenco dei dischi, partizioni, UUID e PARTUUID.
Il resto della riga è spiegato bene nella documentazione citata sopra.
Comunque, volendo spiegarla brevemente
UUID=... indica il disco contenente il file system che vogliamo montare;
/media/dati identifica il punto di mount;
ntfs-3g indica il tipo di file system, dato che la partizione è formattata NTFS bisognerà usare il driver ntfs-3g;
defaults,uid... sono tutte le opzioni di accesso al dispositivo, sono spiegate bene nel wiki di Fstab riportato sopra;
0 e 0 finali identificano rispettivamente dump e pass spiegati bene anch'essi nella documentazione.
Le opzioni significative per gli accessi sono uid (user-ID), gid (group-ID), dmask (Directory Mask) e fmask (File Mask).
Per trovare uid e gid dell'utente che si desidera inserire basta digitare da terminale
id nome-utente
Oppure solo id.
Normalmente l'utente connesso ha id e gid pari a 1000. Il problema, però, è che Apache opera tramite l'utente www-data.
Se digitiamo infatti
id www-data
noteremo che tale utente non ha l'id 1000, quindi non riuscirà ad accedere al disco.
Allo stesso modo, se in fstab assegnamo id ed gid di www-data sarà poi l'utente loggato a non riuscire più ad accedervi. Per ovviare al problema potremmo aggiungere l'utente www-data al gruppo 1000 (ossia al gruppo dell'utente loggato) e cambiare uid e gid nelle opzioni in fstab.
Per fare ciò basta digitare:
sudo usermod -a -G gruppo_utente www-data
Usare l'opzione -a solo con l'opzione -G.
Per verificarne la correttezza digitare:
id www-data
e vedremo comparire id, gid e gruppi di appartenenza dell'utente www-data.
Per visualizzare i gruppi di appartenenza dell'utente www-data si può anche usare il comando:
groups www-data
Una volta impostati montaggio e permessi (per i permessi vedere in seguito la sezione "considerazioni"), basterà creare un collegamento simbolico all'interno della directory di lavoro di Apache (che ricordo essere, nel mio caso, /home/nome-utente/www) che punti al disco in questione o, meglio ancora, ad una sua sottodirectory.
Per esempio, se nel disco NTFS abbiamo creato una directory chiamata www2, destinata appunto all'utilizzo con Apache, per creare il link dovremmo digitare:
ln -s /media/DATI/www2 /home/nome-utente/www/nome-link
CONSIDERAZIONI:
E' da precisare che una volta montata la partizione ed assegnati utente e permessi, questi verranno applicati automaticamente a tutti i file e directory, nuovi e già presenti. Se si creerà un file con utente root per esempio, il file non apparterrà a root (come normalmente accade in una partizione EXT*) ma all'utente specificato in uid, gruppo specificato in gid e i permessi specificati da dmask e fmask. Anche se si proverà a cambiare i permessi o il proprietario di un file, questi non cambieranno. Praticamente tutto sarà ereditato da quanto dichiarato in fstab. Per fare diversamente bisognerà smontare e rimontare la partizione con nuove opzioni.
Questo per ricordare che se si dovesse montare la partizione dando i permessi solo, o in parte, all'utente www-data, l'utente loggato che dovrà operare su tale partizione non avrà poi i permessi necessari per poterlo fare. L'unico modo per operare in queste condizioni sarebbe come utente root ma nonostante ciò i permessi, come detto poche righe sopra, non sarebbero assegnati ad altri se non a quelli specificati in fstab.
Precisato ciò, salta subito all'occhio un problema:
Apache opera con utente www-data, mentre l'utente loggato sarà un altro, quindi, se da un lato www-data dovrà avere accesso in scrittura a tale partizione, e non sarebbe corretto darla ad altri per questioni di sicurezza del server, dall'altro vi è la necessità dell'utente loggato di potere accedere al resto della partizione.
Inoltre, dare i permessi di scrittura a www-data in queste condizioni, ossia o tutti o nessuno, solleverebbe in ogni caso dei forti dubbi sulla sicurezza. Normalmente, infatti, si lasciano ad Apache i permessi di scrittura solo ai file che necessitano di ciò, a tutto il resto andrebbe negata, ma ciò non risulta possibile per quanto detto sopra.
Facciamo un po' di esempi:
(Leggere bene le guide per capire i permessi usando le maschere...
comunque, in soldoni, è una sorta di complemento, quindi 0 diventa 7, 1 diventa 6 e così via.
Ricordo inoltre che la terna dei permessi ottali vede il numero di sinistra "owner", ossia proprietario, il numero centrale identifica "group", permessi al gruppo, il numero a destra "other" ossia tutti gli altri).
Nella guida, verso l'inizio, ho usato un comando per montare la partizione NTFS con queste opzioni:
... nodiratime,noatime,defaults,uid=1000,gid=1000,locale=it_IT.utf8,dmask=027,fmask=137 0 0
cioè, ho montato la partizione con il mio utente (1000) e con permessi 750 per le directory (dmask 027) e 640 per i file (fmask 137).
In questo modo, quindi, il mio utente ha accesso in lettura/scrittura alle directory (7) e per i file (6), ma l'utente www-data no, in quanto essendo identificato come "altri" si trova un paio di zeri nei permessi!
Per questo motivo, nelle righe successive, avevo precisato che per ovviare a tutto ciò si sarebbe potuto aggiungere l'utente www-data al gruppo del mio utente.
Così facendo troviamo, per l'utente www-data, un 5 per le directory ed un 4 per i file, quindi Apache potrà accedere alla partizione ma comunque solo in lettura. Basterà modificare dmask e fmask per dare accesso anche in scrittura anche al nostro gruppo e non solo al nostro utente. Quindi dovremmo modificare il comando in questo modo: dmask=003 (o 007) e fmask=003 (o 007).
Ora anche l'utente www-data, che farà parte del gruppo dell'utente loggato, avrà un 7 su tutto, ma con tutte le conseguenze del caso, cioè che si sta dando ad Apache l'accesso completo a tutti i file.
Se si usa solo come test locale potrebbe anche andare bene, ma se vi dovessero accedere anche altri utenti non sarebbe buona norma di sicurezza...
Ptremmo anche cambiare l'utente con cui opera Apache (cambiando nome utente in /etc/apache2/apache2.conf, che poi preleva da /etc/apache2/envvars) e dare per comodità il nostro utente loggato, ma anche qui ci troveremmo ad avere Apache che opera con i diritti di amministratore ed oltretutto con i permessi di scrittura su ogni file! Peggio ancora direi!
Si potrebbe pensare di restare con tali permessi finchè non si installa il tutto sulla directory in questione, come CMS o altro, una volta sistemato il tutto basterà modificare le opzioni di mount riassegnando a www-data la sola lettura ed esecuzione. Se, però, sul sito locale ci fossero delle funzioni che richiedono l'accesso in scrittura ad alcuni file tutto ciò non ci sarebbe molto utile.
Potrebbe restare in sola lettura una semplice condivisione di foto, musica, documenti o altro...
Insomma, dipende dall'uso che se ne vuole fare.
Concludendo, a mio avviso, non sembra una soluzione comoda nè efficace, se non per una semplice "condivisione" di file che non necessitano di permessi in scrittura.
Oppure si potrebbe trasformare tale partizione in una EXT* e si potranno assegnare permessi specifici per ogni file e rendere tutto più sicuro e corretto. A questo punto, però, Windows non vedrà più tale partizione, se non eventualmente tramite samba se si decidesse di condividerla.
Insomma, su Linux una partizione NTFS non è che sia molto utile... ma per un semplice uso di test o simili, in mancanza di altro, di potrebbe anche fare, certo sarebbe più opportuno pensare altre soluzioni.