Lug 13 2007
Potenziale debolezza di php, memory limit
Casualmente mi sono imbattuto nel dover variare l’impostazione di memory limit su un server di cui non avevo il minimo accesso.
Solitamente infatti sono abituato a sviluppare su server Linux sui quali ho anche poteri di amministratore, in questo caso trattandosi di un hosting su server di un altro provider mi sono imbattuto nel dover aumentare memory_limit per poter far funzionare il noto CRM Sugar Force.
La variabile presente nel php.ini denominata memory_limit ha il compito di limitare il consumo di memoria massimo per uno script php in modo tale da evitare potenziali problemi al server web stesso in caso di cattiva gestione dello script o per qualche loop.
Per default tale valore è impostato ad 8 Mbyte, valore secondo me più che ragionevole.
In pratica Sugar Force richiede la bellezza di 32 Mbyte di memoria (se non erro) per poter funzionare.
Fatto sta che il provider in questione (giustamente) aveva l’impostazione di memory limit globale settata a 8 Mbyte e non funzionava una mazza…
Dubbioso sul poter realmente variare tale impostazione sono andato sul sito di php e nell’appendix ho scoperto quello che MAI mi sarei aspettato:
| memory_limit | “8M” | PHP_INI_ALL |
PHP_INI_ALL per intenderci indica che il valore è variabile da QUALUNQUE script php! Nemmeno come PHP_INI_PERDIR che indica invece che il valore è variabile o per directory da configurazione generale di apache o da .htaccess (se consentito Override da apache).
Insomma, nel caso specifico mi è anche andata bene perchà© ho potuto comodamente caricare in .htaccess “php_value memory_limit 64M” per poter far funzionare il CRM perà questa cosa per me ha aperto un forte dubbio su tale scelta fatta dagli sviluppatori di php e in particolare dalla Zend.
Fortunatamente la soluzione è abbastanza facile, è infatti sufficiente disabilitare l’Override di apache ([per altro impostazione di default] non rendendo effettive le direttive di .htaccess che vengono quindi ignorate) e disattivando da php.ini la possibilità di utilizzare la funzione ini_set().
Perà per un provider che eroga hosting per chiunque acquista uno spazio web (magari a prezzi stracciati) diventa limitativo e restrittivo.
Penso che un approccio diverso da parte della Zend e degli sviluppatori di php in merito a tale configurazione sarebbe più opportuno… almeno per le nuove versioni e configurazioni di default.
Ciao. Maxgrante
info[AT]massimo-caselli[DOT]com
Anche a me è capitato che 8MB di memory limit non siano stati sufficienti (per svolgere diverse operazioni su un database con migliaia di utenti…), ed alla fine ho dovuto rinunciare ad alcune funzionalità …
Un provider che eroga un servizio deve settare il memory_limit ad un valore ragionevole, 8Mb è basso.
Io ho fatto un servizio di hosting linux utilizzato da molte persone e l’8Mb l’ho dovuto alzare in fretta… ci vogliono ALMENO 12Mb per le moderne applicazioni.
Nel tuo caso il provider ha commesso un grosso errore di sicurezza, non tanto per il fatto che puoi aumentarti il memory_limit, ma perchè agendo sull’htaccess puoi cambiare altre impostazioni di sicurezza ben più gravi. E come dici te non è un errore di apache, in quanto l’impostazione di default è alloverride none, quindi sicuro.
Secondo me l’approccio di zend è giusto.
In effetti forse 8 Mbyte sono pochini, almeno per hosting di alta qualità .
Perà per hosting basati sui grossi numeri (Aruba, Tiscali etc…) e orientati più che B2B verso B2C 8 Mbyte possono anche andare e sono forse anche una necessità .
Noi per esempio in Coresis abbiamo 20 Mbyte. Ma il tipo di hosting è orientato verso aziende e non privati.
Io credo che permettere di usare .htaccess sia una necessita per provider che fanno B2C anche a fronte di rischi di sicurezza… Altrimenti sarebbe impossibile gestire mod_rewrite etc…
E comunque permane il problema che la Zend consente di cambiare memory_limit ovunque, anche nel semplice script php…
Ciao. Max
Potrei ‘forse’ dire la mia, visto che amministro un server di hosting
Anche secondo me la Zend fa bene a fare quello che fa, dato che il php non fa solo una cosa, ma come tutti qui sappiamo è in grado di gestire infinite situazioni, quindi, necessita di infiniti aggiustamenti, mi viene da pensare: utente per utente.
Non mi dilungo sul fatto che dovrebbero essere gli script per primi ad essere sicuri, e non cercare di demandare l’aspetto sicurezza di un sito all’amministratore di sistema.
Come è stato già fatto rilevare, impedire agli utenti di usare .htaccess in modo appropriato per i loro scopi, limita proprio cià di cui noi piccoli hoster necessitiamo per sopravvivere, cioè l’utenza :->
Con cià non voglio dire che ammettiamo chiunque e gli lasciamo fare cià che vogliono, ma anzi, monitoriamo continuamente il loro operato, ma neppure possiamo impedire di usare ad esempio il mod_rewrite accampando scuse che ricadano nella sicurezza del server.
Anche perchà© altrimenti non funzionerebbe nemmeno Wordpress.
Ci tocca piuttosto sperare che gli utenti sappiano cià che fanno e controllino i loro script, ma che sopratutto dialoghino con noi quando hanno un problema di qualsivoglia natura, cosa che purtroppo non sempre accade, e spesso lo riconosco, anche per colpa nostra.
Marco GRAZIA
Ciao Marco,
anche io gestisco alcuni server di hosting per Coresis.
Noi in effetti abbiamo impostato questa logica.
Su nessun server viene permesso l’override.
Se è necessario gestire rewriting (cosa che fanno in pochi in autonomia) ci richiedo l’applicazione delle regole a livello di Directory definita nel relativo VirtualHost.
Inoltre abbiamo diviso i web server, uno è per i clienti che comprano lo spazio e poi uppano le loro cose (con FTP ovviamente aperto al mondo) e un altro dove ci vanno solo siti sviluppati da noi o in puro HTML.
In effetti quello che io contesto alla Zend è il fatto che memory_limit possa essere impostato da qualunque parte, script php inclusi.
Fosse solo possibile a livello di Directory/.htaccess sarebbe meglio secondo me.
Saluti e buon lavoro collega!
Max