Apr | 11
02
Sabato
Il modulo suPHP per Apache |
|
|
|||
|
Autore :
BigHam » Questo articolo è stato letto: 5114 volte » |
|||||
|
Premetto subito, a scanso di equivoci, che non si tratta di un modulo da installare in Joomla, che non è una estensione ma una caratteristica implementata lato server e che quindi l'utente non può gestire ma solo richiedere al proprio fornitore. Per definizione suPHP è uno strumento per eseguire gli script php su un server web usando i permessi del proprietario dei file e delle cartelle del sito. Esso è composto da un modulo di Apache (mod_suphp) e un file binario che viene chiamato dal modulo Apache per modificare l'UID (user id) del processo che esegue l'interprete PHP (tradotto dal sito ufficiale di suPHP). Quindi un servizio di Hosting che usi questo modulo (o altre valide alternative) mette al primo posto la sicurezza dei suoi server condivisi. Un’alternativa a suPHP è suEXEC altro modulo per Apache con caratteristiche simili. E a proposito di permessi vi invito a leggere questo articolo che li descrive più nel dettaglio, ovviamente sull’argomento c’è moltissimo materiale in rete A questo punto facciamo alcune puntualizzazioni:
Se il nostro fosse un semplice sito realizzato in html non ci faremmo tante paturnie ma Joomla (e in genere tutti i cms) ha una caratteristica fondamentale: possiede delle funzionalità che consentono al webmaster di gestire il proprio sito in maniera dinamica sia aggiungendo contenuti sia installando nuove estensioni per ampliare le funzionalità del sito stesso. E per farlo utilizza delle pagine, il cosiddetto backend, che contengono codice php che il server deve eseguire. E proprio qui casca l’asino! Joomla permette, attraverso il backend, di installare nuove estensioni, mettere immagini all’interno dei contenuti, creare dei repository per il download di file, ecc. Queste sono tutte attività che hanno una cosa in comune: il trasferimento di files dal nostro pc alle cartelle del sito che si trovano sul server. Se inseriamo un’immagine in un contenuto in realtà trasferiremo il file dell’immagine nella cartella images del nostro sito, se installiamo una nuova estensione trasferiremo i file che la compongono all’interno delle cartelle del nostro sito. Con Joomla esistono dunque due modi per leggere e scrivere i file contenuti nelle cartelle del sito web: - via browser usando il protocollo http - via client ftp (Filezilla) usando il protocollo ftp Nel primo caso abbiamo due ulteriori possibilità: accedere in lettura ai singoli files, che equivale a visualizzare le pagine del sito web, oppure accedere dal backend di Joomla con la possibilità di scrivere su file esistenti (es. modificare la configurazione di Joomla) o creare nuovi file e cartelle (es. installando una nuova estensione) Nel secondo caso l’accesso tramite client ftp ci permette di modificare i singoli file o crearne di nuovi trasferendo semplicemente i file dal nostro pc alle cartelle del server, senza la mediazione di Joomla. Una sorta di copia e incolla ma tra due computer diversi. Vediamo di capire con un esempio cosa potrebbe accade su un server web (che non usa il modulo suPHP) quando viene trasferito un file dentro una cartella del nostro sito. Ipotesi A: un file (es. un’immagine) viene trasferito nella cartella /images utilizzando Filezilla ![]() L’utente che esegue l’operazione è quello assegnatoci per l’accesso FTP dal nostro servizio di hosting e il numero 1111 è la usa UID (User Identification) che lo rappresenta mentre il numero 1112 è la GID (Group Identification) e rappresenta il gruppo proprietario di appartenenza. Se andiamo a guardare la cartella utilizzando Filezilla potremmo vedere che l’utente e il gruppo proprietario del file sono gli stessi degli altri files. Ciò può sembrare normale ma non è così se leggiamo la seconda ipotesi. Ipotesi B: una estensione viene installata attraverso il backend di joomla ![]() (chiedo venia a JoomlaShow.it per avergli “rubato” l’immagine) L’utente che esegue l’operazione è quello di Apache (stiamo usando il browser per accedere al sito). Se tornando a guardare i files del server con Filezilla notiamo che nella cartella components la cartella dell’estensione appena installata (e tutti i files e cartelle al suo interno) hanno una UID e una GID (utente e gruppo proprietario) diverso dagli altri. Cosa è successo? Nel secondo caso il server ha eseguito gli script php (le pagine joomla) usando l’utente di Apache e di conseguenza ha dato a lui la proprietà dei files (ricordo che stiamo parlando di un server che non usa il modulo suPHP di Apache). Gli altri files hanno una UID e una GID diversi perchè sono stati inizialmente trasferiti via FTP sul server. E quindi adesso che succede? Il problema è che adesso non potremo più intervenire su di essi (ad esempio se volessimo cancellarli) perchè l’utente FTP non ha i diritti di accesso a cartelle e files che non siano di sua proprietà. Mi sembra evidente, a questo punto, che anche se i files avessero avuto il massimo dei permessi di accesso (il famigerato 777 ovvero tutti possono fare tutto su quel files) nulla potremmo più fare se non rivolgerci al servizio di Hosting per ripristinare la proprietà sui files, visto che noi questa operazione non possiamo farla. Diffidate di chi vi propone di impostare a 777 i permessi su file e cartelle su un server web pubblico, non è una soluzione che mette al sicuro il vostro sito. E qui torniamo al modulo suPHP: se questo modulo fosse stato installato, configurato e attivato le cose sarebbero andate diversamente. Già, perchè in quel caso sarebbe stato il modulo a gestire l’esecuzione del codice php contenuto nelle pagine del nostro sito e lo avrebbe fatto sempre e solo con l’utente e il gruppo proprietario dei files, quello assegnatoci dal servizio hosting per l’accesso FTP, anche quando avessimo eseguito le operazioni di upload attraverso il backend di Joomla. ![]() In caso di uso del modulo suPHP se l'estensione viene installata da backend (quindi usando il browser e l'utente generico di Apache) la proprietà dei file rimane all'utente e al gruppo che usiamo anche via ftp. Un'altra caratteristica interessante di suPHP è quella che in ambito hosting, quindi con molti siti di clienti differenti sullo stesso server, le operazioni svolte da ogni sito sono facilmente riconoscibili nei log e nei processi essendo fatte dal relativo utente e non dal generico Apache, consentendo così di risalire più velocemente al sito che stà facendo casino o quale sito è stato bucato. C'è insomma molta più tracciabilità delle operazioni. Conclusione Accertatevi che sul server web sia disponibile il modulo suPHP o un’alternativa come suEXEC. Se questa informazione non è disponibile sulle pagine del sito web del servizio di Hosting (ma se lo usano hanno tutto l’interesse a dichiararlo) inviategli una mail chiedendolo espressamente. Se qualcuno avanzasse la “scusa” che il modulo in questione (o eventuali alternative) impegnano troppe risorse sui server (memoria RAM e CPU) forse dovremmo supporre che tali server sono un pò datati o che ci sono davvero troppi siti web su un singolo server. Su questo a voi le conclusioni. NOTA In ambito reti informatiche si definisce protocollo l’insieme delle regole che governano le attività di scambio di dati fra due o più host. Insomma una sorta di linguaggio comune tra pc e server o tra due pc collegati in rete. Il protocollo http viene usato per il trasferimento dati di pagine ipertestuali (appunto le pagine di un sito web) mentre il protocollo ftp per il trasferimento di files. Per approfondimenti (su wikipedia): Protocolli: Protocollo di rete Protocollo http Protocollo ftp Linux: chmod - permessi linux umask - chown - proprietà sui files
Articoli più recenti:
|







