Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71299
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.173 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <52DCAE75.8070401@sugarcrm.com>
References: <CAGa2bXZEXx7H+atr3LK8OLLQGSd9a-6+Gey+RhPwP0d7EvTBmw@mail.gmail.com>
 <52DC905F.2080705@sugarcrm.com> <CAGa2bXbrr3CreZoaasDFWebSG-f4ai-AcTEiX9BGXZLTvjjb+Q@mail.gmail.com>
 <52DCAE75.8070401@sugarcrm.com>
Date: Mon, 20 Jan 2014 16:13:53 +0900
Message-ID: <CAGa2bXZxVGtFiVLnzCZ55cOY2qhoYnyvoi-MYB9ay1Pw5Dumiw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133b426c43b6404f061a44a
Subject: Re: [PHP-DEV] [VOTE] Introduce session.lock, session.lazy_write and session.lazy_destory
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1133b426c43b6404f061a44a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Stas,

On Mon, Jan 20, 2014 at 2:04 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrot=
e:

> > 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 update=
d
> 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.


I agree that users could get into trouble if they don't know what they are
doing.

To get most out of session.lock=3Doff and session.lazy_write=3Don, proper u=
sage
is needed to get reliable operation

Suppose session only stores authentication info, then session and data
storage
only needs read. Session write (or destroy) is only needed when users are
logged
out. Session write is not needed almost all. PHP could cut session and
storage
load to half and PHP could allow *concurrent* access for apps while app
could
maintain consistency perfectly.

In this scenario, app performance could be boosted a lot by removed write()
calls.

Programmer also don't have to care to call
session_commit()/session_write_close() to
get concurrency. Session module writes session data when it is needed.
(Programmers
must be careful about concurrent write() calls, though)

At least I'll use this and there would be certain number of users who use
like this
for better performance.

Users, who want correct access counts or like, should not use
session.lock=3Doff.
session.lazy_write=3Don will not give any benefits if program updates
$_SESSION
for every request.

> 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?


Strict session is to prevent session to initialize with user supplied
session ID.
In this case, session ID is initialized by PHP and I would like to allow
access to
deleted session for a while to prevent race condition that creates unneeded
new session ID (and it's data).


> 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.
>

Current session module implementation and web technology allows to access
old session ID when session ID is regenerated. As you described, session X
could
remain deleted.

   Request A                              Request B
        =E2=86=93                                                |
   Access session X                           =E2=86=93
        |                                        Access session X (if
locked, Req. B waits )
       =E2=86=93                                                 =E2=86=93
   Regenerate ID (Del X, New Y) session X unlocked (Del X unlocks)
       =E2=86=93                                                 =E2=86=93
   Close session Y                    Close session X (For files, inode is
marked deleted remain deleted)




However, this could happen also.

   Request A                              Request B
        =E2=86=93                                                |
   Access session X                           |
       =E2=86=93                                                 |
   Regenerate ID (Del X, New Y)        |
       =E2=86=93                                                 |
   Close session Y                             |
                                                 Access session X
                                                         =E2=86=93
                                                 Session X is created
(use_strict_mode=3Don creates session Z)
                                                         =E2=86=93
                                                 Close session X (Session X
or Z remains)

Without strict session, old session X could remain. With strict session,
unneeded Z could remain.
Even if programmers want to delete session X, session X could be
reinitialized by default config.

There are more cases with session.lock=3Doff.



> 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?
>

It's described in previous.
Users wouldn't, but system might do.



> > 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=3DOn.
>
> It of course may be reinitialized, but what's wrong with that? Deleted
> data would not be accessible anyway - the data is already gone.
>

I have to double check, but for example, current files do not wipe data
file content. It's a simple unlink. I suppose it has old data. It will be
inaccessible
eventually as described, though.

For database based session, reading deleted data should be result in error.
(e.g. Serializable transaction isolation level is needed for this)


> > 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.


It allows access to old session for certain amount of time. 30 seconds
would be enough for session.lock=3Doff. 60 or more when session.lock=3Don.
I was about to allow access to deleted session for 90 seconds.
Configurable INI may be better. I'll make session.lazy_destroy a integer
config.


>  > 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 may simply ignore new INI config since there may not be codes support
new options.
files_ext is "files + new INI config support".

IIRC you're one of them who are preferred to have separate
implementation(?)
I don't mind at all to remove files_ext proposal.


> > 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?


No, they don't have to. They can ignore new features or implement them
all or part of them.

I would like to know session save handler capability. I'll add save handler
API
that declares it's capability.

I'll update the RFC later.
Thank you for your comment. The RFC is getting better.

I understand your anxiety.  I'm not going to change current behavior,
just adding new features for advanced save handlers and users.
I'll write big caution to the manual also.

Shooting their own foot is possible, but let advanced users to enjoy
extreme performance!

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1133b426c43b6404f061a44a--