[performance & sicurezza] il programma riscrive se stesso

[skidx]

Salve, sto ragionando sulle soluzioni ottimali per una certa applicazione e vorrei sottoporvi una questione, per avere le vostre opinioni. Scusate per l'eventuale lunghezza, spero abbiate la pazienza di arrivare in fondo ancora svegli

L'applicazione è modulare, e i vari moduli non sono sempre necessari. C'è uno script principale che viene usato sempre e si occupa dell'inclusione degli eventuali moduli quando necessari.
Lo schema tipico (lo esprimo in linguaggio informale) è qualcosa come:
if(modulo1 è necessario) allora includi modulo1;
if(modulo2 è necessario) allora includi modulo2;
if(modulo3 è necessario) allora includi modulo3;
...
if(moduloN è necessario) allora includi moduloN;

La cosa da tenere presente è che la configurazione dell'applicazione (e quindi l'insieme dei moduli richiesti) cambia molto raramente, quando cioè il proprietario del sito che la usa decide di aggiungere (o togliere) delle funzionalità (cosa che uno non fa ogni 5 minuti).
Quindi ho pensato che:
1) quando un modulo non mi serve, ripetere a ogni pagina richiesta il controllo corrispondente (if modulo è necessario...) è una perdita di tempo.
2) anche quando un modulo mi serve, ripetere ogni volta il controllo è una perdita di tempo.

Allora ho ipotizzato: quando decido di cambiare configurazione (evento raro), il programma potrebbe riscrivere in automatico lo script principale che si occupa delle inclusioni evitando quindi tutti quei controlli inutili, con il risultato di avere uno script sempre ottimizzato sulle particolari esigenze di chi lo usa.
Una sorta di "ricompilazione del kernel", come avviene nei sistemi linux.
Fin qui l'aspetto positivo. Ora vorrei discutere con voi gli aspetti negativi.

Il primo requisito lo dico io, è che la cartella che ospita l'applicazione dovrebbe permettere la scrittura a tutti (777). Io non so quali siano nel dettaglio i rischi che comporta una scelta di questo tipo, mi piacerebbe saperlo da voi, magari con degli esempi.

Altro dubbio, la riscrittura dello script mentre questo viene anche richiesto in esecuzione da diversi client (ipotizziamo un sito molto visitato) che problemi comporta?

etc. etc. spazio a voi.

[andr3a]

non puoi scegliere e modificare le dipendenze in database ?
in area admin scegi cosa serve e cosa no, in base a questo popoli, modifichi o cambi il campo unico moduli di tipo text e nella index con una query e un eval( $risultato['moduli'] ); dove $risultato['moduli'] sara' un testo con una serie ordinata di include o require separati da ; ... riscriversi secondo me e' poco raccomandabile ma potresti scrivere da un' altra parte e poi riscrivere con un bel lock la index in un secondo momento ( tipo "applica cambiamenti" e il programma prima crea index_temp.php, poi apre in lock "w" index.php mette tutto il contenuto di index_temp.php, slocka, chiude ed elimina , se il contenuto dei 2 files e' identico, index_temp.php ... se non e' identico rifa' l' operazione perche' qualcosa e' andato storto ... )

ma a parte questo trovo poco sicuro una 777 di default alla base del sito, non puoi usare una cartella sotto la web che non e' raggiungibile via http ?
in quel caso faresti tutto e con calma li dove l' index andra' a leggersi solo quel file ... altro non mi viene in mente

[skidx]

[supersaibal]Originariamente inviato da andr3a
non puoi scegliere e modificare le dipendenze in database ?
[/supersaibal]

Sì, certo. Il problema non verteva su dove e come memorizzare la configurazione, quanto sull'ottimizzare poi lo script che si occupa di gestire il tutto (chiamiamolo il "kernel" dell'applicazione, che fa un sacco sborone ).
Quindi a regime meno query si fanno meglio è.

[supersaibal]scrivere da un' altra parte e poi riscrivere con un bel lock la index in un secondo momento [/supersaibal]

Bene, io il lock non l'ho mai usato. Nel momento del blocco gli altri utenti che richiedono lo script rimangono in attesa o ricevono un 404 (o altro errore)?

[supersaibal]ma a parte questo trovo poco sicuro una 777 di default alla base del sito, non puoi usare una cartella sotto la web che non e' raggiungibile via http ?[/supersaibal]

Io sul mio sito potrei fare come mi pare, e la tua soluzione è senz'altro sicura, ma non può diventare un requisito perché in gran parte degli hosting in circolazione non ti fanno mettere script fuori dalla document root.
Mi sapresti fare qualche esempio per cui avere 777 sulla document root mi comprometterebbe assai?

Ah, grazie.

[andr3a]

[supersaibal]Originariamente inviato da skidx
Bene, io il lock non l'ho mai usato. Nel momento del blocco gli altri utenti che richiedono lo script rimangono in attesa o ricevono un 404 (o altro errore)?[/supersaibal]

dovrebbero restare in attesa che il file sia sblockato ... per poi leggerlo, ma non ne sono sicuro ... sul manuale non dice di preciso cosa accade per chi prova ad accedere ( dall' esterno )


comunque:

$fp = &fopen( $file, 'w' );
@flock( $fp, LOCK_EX );
fwrite( $fp, $testo );
@flock( $fp, LOCK_UN );
fclose( $fp);

piu' semplice di cosi'

[supersaibal]Originariamente inviato da skidx
Mi sapresti fare qualche esempio per cui avere 777 sulla document root mi comprometterebbe assai?
[/supersaibal]

non lo so, considera che se esistono i permessi e di default sono non permissivi un motivo ci sara'

senti daniele_dll per questo

[skidx]

aap

[Gianni_T]

Penso che ti stia facendo eccessivi problemi sul peso di quei controlli. Ci sono dei CMS che si sparano più di 100 query a pagina...

Comunque, hai valutato la possibilità di mettere in piedi un sistema di cache?

[M4rko]

Se un file è lockato, il processo che lo richiede (quindi apache) rimane normalmente in attesa di avere la risorsa libera. Ma si tratta di solito di attese infinitesimali, di cui l'utente nemmeno si accorge.

Il fatto di usare un file a 0777 vuol dire semplicemente che qualunque utente puo scriverci sopra, ed è una scelta insicura. Poi le valutazioni sulla sicurezza si fanno di caso in caso: sei in hosting? quanti altri utenti ci sono sullo stesso server? safe_mode? sullo stesso server girano altri servizi? ci sono utenti che hanno accesso via shell? ecc.ecc.

Se dovessi implementare una cosa del genere, sceglierei di mettere il tutto su database come ti aveva suggerito andrea.

[andr3a]

infatti stavo per entrare e linkare il 3D dove gente si sfoglia tutto ... oltre a leggere i tuoi files, con un 777 in root puo' anche permettersi di cancellarli, eliminarli o sovrascriverli ... sta' molto sulla configurazione dell' host ed e' comunque una cartella "libera" dove un errore umano dello sviluppatore stesso potrebbe rendere vuota una cartella ( un semplice unlink su root perche' il percorso non e' stato ben parsato ... difficile ma puo' capitare )

insomma, no 0777 sulla root, 1 query su un semplice campo a chiave unica, o senza chiave, invece non comporta assolutamente niente

[skidx]

[supersaibal]Originariamente inviato da Gianni_T
Ci sono dei CMS che si sparano più di 100 query a pagina...[/supersaibal]

Ed è proprio quello che voglio evitare di fare. Il thread appunto parla di performance

[supersaibal]Comunque, hai valutato la possibilità di mettere in piedi un sistema di cache? [/supersaibal]

Sì, ma la cache mi serve per i dati da mandare in output, qua si trattava di snellire il codice di gestione, mediante riscrittura ottimizzata.

Andrea e Marco, grazie per le info sui permessi e sulla sicurezza. Se invece della root fosse solo una sottodirectory apposita ad avere permesso di scrittura la cosa sarebbe ragionevolmente fattibile?

[andr3a]

entro i limiti, considerando che ci sara' il file principale di gestione e che una 777 non e' sicura, per ogni apertura del file dovrai fare un
if( file_exists( 'cartella/main.structure.php' ) ) ...
con relativa ricreazione presa da un' altra parte in caso di false

... e a questo punto tra una query su tabella main_includes a singolo campo text e tutti sti' controlli fai un po' tu cosa e' meglio ...


non e' una query su SELECT semplicissima a comportare calo di prestazioni, sicuramente avrai moltissime altre gatte da pelare per ottimizzare le tue performance ... imho stai perdendo tempo dietro l'ultimo ostacolo alle performance dell' applicativo