Perché Debian pulisce le sessioni php con un cron job invece di usare il garbage collector integrato di php?

26

Debian e derivati (Ubuntu) non usano il garbage collector della sessione php

session.gc_probability = 0

invece usano un cron /etc/cron.d/php5

09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete

Perché Debian ha scelto di farlo?

— NULLL
fonte

29

Perché Debian imposta permessi molto severi su /var/lib/php5(1733, root del proprietario, root del gruppo) per prevenire il dirottamento della sessione PHP. Sfortunatamente, questo impedisce anche al garbage collector della sessione PHP nativa di funzionare, perché non può vedere lì i file della sessione. Il cron job viene eseguito come root, che ha accesso sufficiente per visualizzare e ripulire i file di sessione.

Modifica : documentazione di supporto: il comportamento è stato stabilito in risposta al bug # 267720 . (C'erano commenti nel php.inifile di scorta su questo, ma non li vedo lì ora nella mia installazione di PHP basata su wheezy.)

— asciiphil
fonte

Perm su / var / lib / php5 ar drwx-wx-wt (rooot-root), quindi l'utente apache può scrivere il contenuto della directory (bit appiccicoso), ma non può leggerlo. Quindi capisco che il garbage collector di php non sarà in grado di valutare l'atime dei file di sessione, quindi non può scegliere quali file eliminare ... ho ragione?

— null

Sì, è corretto.

— asciiphil,

5

È probabile che sia un po 'più affidabile sui siti a basso traffico (se ottieni solo un paio di centinaia di colpi al giorno e GC spara solo ogni mille o giù di lì, le sessioni potrebbero rimanere più lunghe di quanto dovrebbero) e immagino che potrebbe essere un un po 'meno duro sul server rispetto al GC nativo se hai molte sessioni.

— ceejayoz
fonte