Cosa sono e come condizionano l'esecuzione degli script php
Qualcuno potrebbe chiedersi perchè, in un sito dove si parla di programmazione Php, dovremmo occuparci del funzionamento dei permessi sui files In effetti potrebbe apparire un argomento che può interessare soprattutto gli aspiranti amministratori anzichè chi realizza pagine WEB. In realtà il sistema dei permessi condiziona non soltanto la sicurezza generale del server, ma anche la gestione dello spazio in cui opera lo sviluppatore: non di rado script sintatticamente corretti funzionano diversamente da come ci si potrebbe aspettare proprio a causa di una mancata comprensione delle autorizzazioni sui files.
Negli esempi che seguiranno prenderemo in considerazione prevalentemente il sistema dei permessi su server Unix-like, tuttavia gran parte delle osservazioni varranno anche per OS come Windows NT/2000/XP, con l'unica precisazione che in questi ultimi non è possibile impostare le autorizzazioni via FTP.
Errori "inspiegabili"
Spesso il programmatore alle prime armi che sta tentando di adattare alle proprie esigenze uno script già pronto, che comporta la lettura, la creazione e/o la scrittura di files e directory nel suo spazio WEB, incontra errori come i seguenti:
Warning: Unable to create '/home/sites/heller/www/upload/ feather3.gif': Permission denied in /home/sites/infodiritto/www/upload.php on line 26
Warning: Unable to move '/tmp/phpPzxl9A' to '/home/sites/heller/www/upload/ feather3.gif' in /home/sites/infodiritto/www/upload.php on line 26
Questo potrebbe essere il caso di un sistema che consente l'upload di files via HTTP dal proprio PC ad una directory remota creata dal programma, ma è soltanto uno tra i molti esempi po
Cosa sta succedendo?
Apparentemente il codice è corretto, eppure nulla va per il verso giusto.... Chi chiede aiuto a colleghi più esperti quasi sempre si sente dare una risposta simile alla seguente:
"Hai settato i permessi di lettura/scrittura sulla directory per l'upload? No?? Bene allora "chmodda" tutto a 777"
Il neofita, magari dopo aver ottenuto qualche spiegazione pratica su come si faccia chmod via FTP (o telnet qualora gli sia consentito), esegue gli ordini senza porsi troppe domande e.....all'improvviso l'upload funziona!
Solitamente l'interesse per il sistema dei permessi si esaurisce qui per risvegliarsi, inevitabilmente, al verificarsi del prossimo problema.
Aiuto non riesco più a cancellare file e directory!
L'upload manager funziona perfettamente per giorni, fino a quando un utente burlone ci invia un'immagine della sua diva a luci rosse preferita. Un sistema di gestione degli upload ben fatto, oltre a permettere ai navigatori di inserire file, dovrebbe consentire anche al proprietario dello spazio WEB di eliminare quelli indesiderati, ma sfortunatamente quello che ci è toccato non è tra i più completi.
La soluzione più semplice sembrerebbe collegarsi via FTP per cancellare la foto "scomoda" ma....purtroppo al primo tentativo di eliminazione ci accorgiamo che l'operazione non ci è consentita.
Allora tentiamo di modificare i permessi della directory in cui vengono salvati i files e scopriamo che semplicemente il comando chmod viene ignorato. A questo punto capita persino di dover contattare l'assistenza dell'ISP chiedendo il favore di eliminare il file.
Ma cosa è accaduto esattamente? È mai possibile che io nel mio spazio WEB non possa eliminare un file uplodato da un estraneo?
Accantoniamo la questione per un istante perchè è il momento di esaminare il funzionamento delle autorizzazioni sui files.
Lettura, scrittura ed esecuzione
Ad ogni file nel server possono essere assegnati 3 tipi di autorizzazioni, ed ognuna ha il compito di consentire a chi ne sarà titolare l'operazione corrispondente:
- lettura (identificata dalla lettera r oppure con la cifra 4 nel formato ottale)
il significato è evidente: il file sarà leggibile da chiunque si vedrà assegnare questa permesso d'accesso. - scrittura (w oppure 2)
il file sarà modificabile - esecuzione (x oppure 1)
se si tatta di un file di tipo eseguibile potrà essere eseguito
Per quanto riguarda le directory il discorso è analogo, ma con alcune distinzioni rilevanti:
Il permesso di lettura consente al titolare di ottenere la lista dei files contenuti nella directory, quello di esecuzione dà la possibilità di accedere alla directory, mentre quello di scrittura consente di creare e cancellare nuovi file e nuove directory all'interno di quella cui si l'autorizzazione si riferisce.
Ne consegue, ad esempio, che il tentativo di accesso ad una directory che abbia i permessi esecuzione ma non quelli di lettura, attraverso un percorso come "/home/miosito/directory_in_questione", sfocerà in un errore; ma i singoli file in essa contenuti, purchè abbiano ricevuto l'autorizzazione in lettura, sono perfettamente raggiungibili attraverso i rispettivi path completi, come "/home/miosito/directory_in_questione/un_file_qualsiasi.txt".
Chi sono i titolari di queste autorizzazioni?
I soggetti individuabili sono 3:
- il proprietario del file (owner)
- i membri di un gruppo cui appartiene il proprietario (group)
- gli utenti che non ricadono nelle due categorie precedenti (others).
Pertanto un ipotetico file con permessi 777 (4+2+1=7) o rwx-rwx-rwx sarà pienamente ed egualmente accessibile ai 3 soggetti; mentre 744 (4+2+1/4+0+0/4+0+0) o rwx-r-r indica la piena disponibilità soltanto per il proprietario, mentre concede agli appartenenti a "group" e "others" il mero accesso in lettura.
Soltanto il proprietario del file può attribuire le autorizzazioni (applicando il comando Unix CHMOD), e assegnare un file ad un gruppo differente (purchè egli ne faccia parte), mentre esclusivamente root (l'amministratore) può mdificare la proprietà di un file.
Gli "owners" in uno spazio WEB
A chi corrispondono i soggetti che abbiamo appena esaminato nell'ambito dello spazio WEB che ospita il nostro sito? Chi è "owner" e chi "other" rispetto ai file in esso contenuti?
Ecco un mini vademecum per fare chiarezza
L'utente proprietario dello spazio WEB e l' utente con cui viene eseguito Apache generalmente sono "Others" l'uno nei confronti dell'altro.
In una stessa macchina che ospita diversi siti mediante VirtualHost, generalmente l'utente del webserver è lo stesso per tutti (solitamente "nobody") mentre i file nei diversi spazi fanno riferimento ognuno ad un utente distinto.
Ne consegue che l'"owner" di un file caricato via FTP o di una directory creata nello stesso modo è l'utente FTP, cioè noi che abbiamo aquistato lo spazio WEB.
Invece l'"owner" di file e directory creati attraverso l'esecuzione di uno script php (mkdir() per creare una directory, fopen() oppure touch() per creare un file) appartengono all'utente "nobody": infatti qualsiasi script eseguito dal Webserver eredità i permessi di quest'ultimo.
Da ciò deriva la situazione apparentemente paradossale per cui un file .php da noi caricato sul server ci appartiene, ma opererà con permessi differenti da quelli a noi assegnati.
Affinchè file e directory generati via Php risultino in qualche modo accessibili a all'utente FTP, devono essere loro attribuiti gli adeguati permessi per "others".
Viceversa, in modo speculare, per gli elementi generati o caricati via FTP (o altra modalità di accesso).
È bene assegnare i permessi in scrittura ad "others" esclusivamente quando sono indispensabili, purtroppo non è possibile limitare l'accesso in lettura altrimenti Apache non sarà in grado di fornire alcuna pagina ai visitatori, nè di eseguire alcun script.
File o directory creati tramite scripting non sono "chmodabili" via FTP, ma soltanto tramite uno altro script php (vedi funzione chmod()). Allo stesso modo non è possibile "chmodare" tramite Php file e directory appartenenti all'utente FTP.
Se Php viene eseguito come modulo di Apache gli unici permessi necessari a "others" (cioè Apache) per l'esecuzione di una pagina .php (inserita dall'utente FTP) sono quelli di lettura (704). Qualora gli script siano CGI diviene necessario anche il permesso di esecuzione (705): nel primo caso Apache deve poter leggere lo script, nel secondo deve poter eseguire un programma esterno.
La soluzione del problema
Alla luce di quanto appena detto, come possiamo risolvere il problema posto a pagina 3 di questo articolo?
Ogni qual volta risulti impossibile avere accesso a un file presente nel nostro spazio WEB tramite FTP dobbiamo prima di tutto comprendere se il proprietario sia differente dall'utente con cui stiamo cercando di accedere, quindi capire se quest'ultimo abbia i permessi necessari.
Se non amiamo le connessioni FTP tramite linea di comando, esistono client a interfaccia grafica come CuteFTP-Pro che consentono di ricavare questa informazione semplicemente cliccando con il tasto destro del mouse sull'elemento che ci interessa, e selezionando successivamente "Properties".
In alternativa possiamo ricavare l'"owner" e altre informazioni utili anche tramite il nostro linguaggio lato-server preferito:
<?php
//Pagina fileinfos.php
if(isset($_GET["element"])){//startif
$element=$_GET["element"] ;
if(!file_exists($element)){
exit("L'elemento non esiste") ;
}
$uid=fileowner($element) ;
echo("Id utente --> ".$uid."
") ;
$owner_info=posix_getpwuid($uid) ;
$group_info=posix_getgrgid($owner_info["gid"]) ;
echo("Array informazioni sull'utente
") ;
foreach($owner_info as $key => $value){
echo($key." --> ".$value."
") ;
}
echo("Array informazioni sul gruppo
") ;
foreach($group_info as $key => $value){
echo($key." --> ".$value."
") ;
}
echo("Informazioni sui permessi
") ;
/*
Restituisce i permessi in modalità ottale
*/
echo(decoct(fileperms($element))) ;
}//endif
else{
echo("Indica un file o una directory indicando "?element=nome_elemento" nella query string") ;
}
?>
Il codice appena visto stamperà tutti i dati necessari (e anche di più) sull'elemento che indicheremo nella query_string in questo modo: http://www.dominio.com/percorso/fileinfos.php?element=nome_elemento
Qualora scoprissimo che tale elemento appartiene all'utente di Apache, e che all'utente FTP mancano i permessi necessari ad una data operazione, abbiamo due possibilità: continuare ad accedervi soltanto attraverso script oppure effettuare chmod tramite Php per concedere gli adeguati permessi ad "others".
Conclusione
Il fatto che in un server condiviso da più siti tutti gli script in esecuzione operino con le autorizzazioni di un unico utente, quello del webserver comune ai diversi siti, dovrebbe portarci a riflettere e far suonare qualche campanello di allarme.
Non a caso nell'articolo della prossima settimana ci occuperemo dei problemi relativi alla sicurezza che questa situazione può comportare e delle possibili contromisure, tra cui la configurazione di Php nel famigerato "safe mode".
