Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71295
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.123 as permitted sender)
Message-ID: <52DCAE75.8070401@sugarcrm.com>
Date: Sun, 19 Jan 2014 21:04:53 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXZEXx7H+atr3LK8OLLQGSd9a-6+Gey+RhPwP0d7EvTBmw@mail.gmail.com> <52DC905F.2080705@sugarcrm.com> <CAGa2bXbrr3CreZoaasDFWebSG-f4ai-AcTEiX9BGXZLTvjjb+Q@mail.gmail.com>
In-Reply-To: <CAGa2bXbrr3CreZoaasDFWebSG-f4ai-AcTEiX9BGXZLTvjjb+Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] Introduce session.lock, session.lazy_write and
 session.lazy_destory
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> Unlocked session could be more usable by session.lazy_write. According
> to current implementation, "the last session wins". With session.lazy_write, "the
> last session *writes data* wins". This behavior prevents loosing updated data. It's
> better for performance also.

I think it's not a good idea. This creates a setup where you never know
if your action on session state would actually result in any action at
all. It would be as good for performance as a database that skips random
data writes. Performance may be great, but nobody would use such
database because it's unreliable. I don't think we should put into PHP a
mechanism that sets up users for trouble.

> With AJAX or browser supports concurrent access to server, 
> concurrent access to server is possible. 
> 
> When session ID is regenerated, it is possible that some connections
> access to 
> server with old session ID. i.e. Race condition. 

I don't see how it is possible. I.e. it can access with the old ID, but
if it happened before the session was deleted, then it gets the session,
if it happens after, it gets "no session". Isn't that why you proposed
strict sessions? It of course is also possible to handle without it -
request after deletion would get empty session state and would have to
return error message and have the client to re-request with correct
session state.
Do you mean that somebody would regenerate the id but not destroy the
old session? I don't see how it would be useful - if you have any
security context, the whole point is to destroy the old session, why
won't you do that?

> When this happened, old session that may be known to attacker may be 
> reinitialized or new unneeded session ID is created when use_strict_mode=On.

It of course may be reinitialized, but what's wrong with that? Deleted
data would not be accessible anyway - the data is already gone.

> Allowing access to old session data for a while prevents these cases
> that initialize unneeded session. 

*That* would be a security hole - the system thinks the user was logged
out but you allow anybody who still has old session ID still access the
session as if nothing happened? That's not good at all.

> No. It's applicable to all save handlers.

Then what's the point of proposing additional handler if it applies to
all handlers anyway?

> files save handler is default save handler and there were comments that
> want separate implementation for files. That's the reason why there is such 
> voting option.
> 
> files and files_ext would be identical code except the code supports
> proposed options. I would like to have single code for easier
> maintenace. IMHO.

I don't understand. If all save handlers have this option, what is the
point of existence of both files and files_ext? And what about other
handlers - do they also have to have _ext versions?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227