Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56716 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 95886 invoked from network); 2 Dec 2011 07:38:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Dec 2011 07:38:35 -0000 Authentication-Results: pb1.pair.com smtp.mail=dk@uw.no; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=dk@uw.no; sender-id=unknown Received-SPF: error (pb1.pair.com: domain uw.no from 195.159.98.120 cause and error) X-PHP-List-Original-Sender: dk@uw.no X-Host-Fingerprint: 195.159.98.120 in.cluded.net Linux 2.4/2.6 Received: from [195.159.98.120] ([195.159.98.120:50695] helo=in.cluded.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 82/A2-15959-97088DE4 for ; Fri, 02 Dec 2011 02:38:34 -0500 Received: (qmail 2379 invoked from network); 1 Dec 2011 09:14:42 -0000 Received: from 78.225.251.212.customer.cdi.no (HELO ?10.0.0.100?) (daniel@212.251.225.78) by in.cluded.net with ESMTPA; 1 Dec 2011 09:14:42 -0000 Message-ID: <4ED8805B.7070308@uw.no> Date: Fri, 02 Dec 2011 07:38:03 +0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060307 SeaMonkey/1.5a MIME-Version: 1.0 To: Yasuo Ohgaki CC: Rasmus Lerdorf , internals@lists.php.net References: <4EBDC283.3040700@yahoo.co.jp> <4ED727FB.7030001@uw.no> <4ED76013.50601@lerdorf.com> <4ED85560.6040101@uw.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Strict session? From: dk@uw.no ("Daniel K.") Yasuo Ohgaki wrote: > 2011/12/2 Daniel K. : >> Yasuo Ohgaki wrote: >>> 2011/12/2 Yasuo Ohgaki : >> Search for a + followed by only tabs or spaces. Empty lines should be >> just that, empty. > > Does CODING_STANDARDS mention this? I hope not, this should be obvious. >>>> Since Daniel mentioned that he cannot disable strict session, >> >> I did no such thing. from where did you get that idea? >> > > Because you wrote this. You cut out the essential lines before: >>>> It removes session read failure retry code from >>>> php_session_initialize() . The retry code may cause infinite loop >>>> depending on save handler implementation. Some session save handlers >>>> may be using this to prevent adoption(?) >> >> I do not believe this could have been used as you speculate. The retry >> logic kicks in when PS_READ_FUNC() fails _and_ additionally sets >> PS(invalid_session_id) Where I proposition that the existing logic (which you removed in your patch) could not have done any looping. Because, then the code below would not have worked. >> This could never work with: >> >> session_id("foo"); >> session_start(); >> >> could it? No code in PHP sets PS(invalid_session_id) in PS_READ_FUNC(), so this must have been added for the benefit of external modules once upon a time. However, the current code seems to never have worked for anyone. If we suppose that it exists an external session module which sets PS(invalid_session_id) in PS_READ_FUNC(), the above sequence of session_id("foo"); session_start(); would have left you with a NULL session_id, then a new one would have been created after goto new_session. I hope someone would have discovered this had they actually implemented such a module. I take this as a sign that no such module exists, but I may of course be wrong in that. >> I am in serious doubt as to whether the additonal restrictions on valid >> characters in session ids are appropriate, and I fear that some poor sod may >> be in for a nasty surpris because of this. >> >> Remember, this is not just about the return value of hash functions, as this >> is used to validate session_ids set with session_id() as well. > > With strict session, user cannot set session ID. If user can, it's not > a strict session, but adoptive. If by 'user' you mean any PHP script, I disagree. The purported goal of the patch was to thwart attempts to choose ones own session_id by sending fake/stale cookies. To also make session_id() unusable from PHP scripts, or to thwart the script-writers ability to choose the session_id seems like a serious bug. > If user would like to use adoptive session, user may set > session.use_strict_mode=0. Of course, but I think we need to find out the semantics, and the expected use case / protection level this new feature is supposed to have. With my current understanding of the patch, and my use of PHP, it seems mostly useless. But, I stress again that I have just read the code, I have not actually used it yet. Daniel K.