#42064 [Fbk->Opn]: exec() deadlocks if another thread is waiting for a file lock

From: Date: Sun, 22 Jul 2007 18:44:13 +0000
Subject: #42064 [Fbk->Opn]: exec() deadlocks if another thread is waiting for a file lock
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-115314@lists.php.net to get a copy of this message
ID: 42064 User updated by: tstarling at wikimedia dot org Reported By: tstarling at wikimedia dot org -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: win32 only PHP Version: 5.2.3 New Comment: I don't really understand what you mean, but I'll take a few guesses: * flock alone is working perfectly, it does not fail. If you replace the passthru() with print(), then the whole thing will work as expected. * The problem doesn't appear to be that passthru() is globally synchronised. The second thread never gets to the passthru() call, you could remove it altogether for f=2 and you would still see the deadlock. * This bug provides the possibility for a DoS attack against any script that calls session_start() followed by a shell execution function. max_execution_time is ignored. Are you telling me that the expected behaviour for this simple script: <?php session_start(); sleep(1); passthru('hello');?> is to consistently deadlock on Windows whenever concurrent requests are sent? Previous Comments: ------------------------------------------------------------------------ [2007-07-22 15:30:04] jani@php.net Isn't this just expected behaviour if you're not checking whether the flock call fails or not?? ------------------------------------------------------------------------ [2007-07-22 02:50:03] tstarling at wikimedia dot org Description: ------------ This appears to be Win32 specific. The shell execution functions, exec(), passthru(), etc., deadlock if another thread in the same server is waiting for a file lock. The most common type of file lock is a lock on a session file, that's where I saw this first. But I could reproduce it with flock() instead of session_start(). The typical way for this to manifest itself is if a browser sends two requests to PHP concurrently, with the same session ID. One request runs first, the other one blocks waiting for a lock on the session file. Then if the running request tries to run exec(), it deadlocks and both threads wait forever. Tested with both Apache 2.0.54 (mpm_winnt) and 1.3.28. I also had a colleague confirm it on an independent system. Reproduce code: --------------- <?php if ( isset( $_REQUEST['f'] ) ) { $f = fopen( 'blah', 'w' ); flock( $f, LOCK_EX ); sleep( 1 ); passthru( "echo Hello" ); } else { $self = $_SERVER['SCRIPT_NAME']; echo <<<EOT <html> <frameset rows="50%, 50%"> <frame src="$self?f=1"/> <frame src="$self?f=2"/> </frameset> </html> EOT; } ?> Expected result: ---------------- The two frames should both display "Hello", after a delay of 2 seconds. Actual result: -------------- The frames take forever to load. Requires a force quit of Apache. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=42064&edit=1

« previous php.bugs (#115314) next »