On Wed, Mar 18, 2015 at 05:57:22PM +0900, Yasuo Ohgaki wrote: > I would like to fix this bug transparently. i.e. User cannot detect already > destroyed > session that is accessible. > > The method is: > > 1. Add "__SESSION_TTL__", which has TTL timestamp, to $_SESSION hash before > serialization. > 2. If session module finds "__SESSION_TTL__" in unserialized data and TTL > is past, then > regenerate session ID and create new session with empty data. (Old session > data is deleted actually) > 3. If session is accessible by step 2, store TTL to PS(ttl) and initialize > $_SESSION without "__SESSION_TTL__". > 4. If PS(ttl) has value greater than 0, add PS(ttl) back to session data > before serialization. > > Note: Serialization/unserialization is done in session module. User cannot > know the existence. > > > I don't think users are using "__SESSION_TTL__" key for $_SESSION, but it > is possible. > If there is invalid "__SESSION_TTL__" in $_SESSION, raise E_NOTICE and > remove the key from > $_SESSION. > > BC happens only when "__SESSION_TTL__" is used by users. > > I would like to fix this in released versions, but it requires addition to > session module globals. > Fix will be only available to PHP7. > > However, PS(ttl) can be added to the end of PS(). If this is OK, I'll fix > this bug from PHP 5.4.
Doh, it's happening again, it was discussed before. Anyway, your solution seems to not fix the real problem behind the bug entry. I suspect that following scenario may occur: http://lxr.php.net/xref/PHP_5_4/ext/session/mod_files.c#429 scenario could be as follows: 1. request A is done with sessid=123 2. A calls session_regenerate_id and is preempted after unlink(2) but before access(2) 3. request B is done with sessid=123 - session_start creates the session 4. request A wakes up, session is written to fs by request B, so destroy fails Please note that if destroy fails, then new session is not generated, possible (but ugly) solution is to call session_regenerate_id again. I didn't verify that, just guessing. Best Regards, Mateusz -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
