#27051 [Com]: Impersonation with FastCGI does not EXEC process as impersonated user

2009-06-24 Thread tgross at m-s dot de 
 ID:   27051
 Comment by:   tgross at m-s dot de
 Reported By:  ghoffer at globalscape dot com
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Windows
 PHP Version:  4.3.4
 New Comment:

When will this bug be fixed?

I compiled PHP myself an added the fix that ghoffer submitted. The fix
works, so would you please add these few lines into PHP?

It's a big problem on our servers that impersonation does not work
correctly.


Previous Comments:


[2008-12-09 00:45:43] louis at steelbytes dot com

I've added a new function to my now inappropriately named
'PHP_Filetimes' http://www.steelbytes.com/?mid=46 (use the *beta*
download)

The new function is a simple wrapper for CreateProcessAsUser that deals
with this problem.

come on PHP/Zend pull ya socks up, I shouldn't have to write my own
extensions to work around such 'bugs'/limitations :-)



[2008-12-08 23:04:23] louis at steelbytes dot com

please please please fix/add this.

it is killing me with 5.2.6 / win2008.



[2007-06-21 18:06:45] aheckmann at m-s dot de

I have the same problem here. Has anything happens in the last three
years on that feature request? The solution seems to be easy, or not?



[2004-01-26 15:41:14] ghoffer at globalscape dot com

Description:

(Related to Bug #10065, but slightly different and more detailed )
Environment:  
Win2K3 running PHP 4.3.4 under FastCGI.  PHP.INI has
fastcgi.impersonate=1.  IIS Site has Anonymous Access OFF and NT
Authentication ON (so that you have to log in to the site as an NT
User).
Up to this point, all is fine: the NT user is being impersonated by the
main thread of PHP so that file access permissions are handled
properly.

HOWEVER, if the PHP script attempts to execute a command (using exec,
or passthru, or similar) then that spawned process is NOT impersonating
the NT account, but rather running under the IIS account.

SUGGESTED RESOLUTION: in proc_open.c, the proc_open function can make a
few calls in lieu of CreateProcess in order to pass along the
Impersonation.  Instead of CreateProcess, it should use
CreateProcessAsUser, passing in the token of the impersonated user
(which PHP is running under).  If it does not do this, per the Win32 API
docs, CreateProcess simply uses the non-impersonated token.

Here is how to run a spawned process as the impersonated user (which
CAN be done conditionally when impersonation is necessary (e.g.,
LOGON_USER is defined; but doing it ALWAYS should in no way impair
security, only a slight hit in performance as three additional API calls
are made):
[ Error checking and variable declarations omitted ]

   OpenThreadToken( GetCurrentThread(), TOKEN_ALL_ACCESS, TRUE, hToken
);  // get impersonation token
   DuplicateTokenEx( hToken, MAXIMUM_ALLOWED, sa,
SecurityImpersonation, TokenPrimary, hToken2 ); // duplicate it for
passing to CreateProcessAsUser
   CreateProcessAsUser( hToken2, ... ) // rest of params are the same
as CreateProcess
   // . . . 
   CloseHandle( hToken2 );
   CloseHandle( hToken );


Reproduce code:
---
?php
  # run this under FastCGI (with fastcgi.impersonate=1 in PHP.INI
  # with NT Auth access to the Virtual Site / Dir that houses the
script.
  # DOIT.bat can be any batch file.  For example, have the batch file
attempt to write a new file to a folder that
  # has ONLY write permissions for the logged-inNT User, NOT the IWAM
account.
  # It will fail because cmd.exe is being executed as IWAM_* even
though
  # we logged into the website and properly impersonated another user.
  $last_line = @exec(cmd.exe /c doit.bat);
?

Expected result:

PHP running as impersonated user under FastCGI should spawn processes
with security context of that impersonated user.

Actual result:
--
The spawned process is being executed in the security context of the
IIS account (IWAM_*).





-- 
Edit this bug report at http://bugs.php.net/?id=27051edit=1

#37676 [NEW]: using Array access operator [] on boolean variable does not show Notice

2006-06-02 Thread tgross at m-s dot de 
From: tgross at m-s dot de
Operating system: Windows XP
PHP version:  5.1.4
PHP Bug Type: Arrays related
Bug description:  using Array access operator [] on boolean variable does not 
show Notice

Description:

When trying to access an array using an undefined offset, PHP displays an
Notice.

However, when you access a boolean variable with any combination of the
array operator [], PHP just returns NULL and displays no error message.

Reproduce code:
---
error_reporting (E_ALL);
$a = false;

var_dump ($a[5]);
var_dump ($a['test'][-3]);


Expected result:

PHP should display a Notice or a Warning.

Actual result:
--
PHP displays
NULL NULL

-- 
Edit bug report at http://bugs.php.net/?id=37676edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=37676r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=37676r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=37676r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37676r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=37676r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=37676r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37676r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37676r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=37676r=support
Expected behavior:http://bugs.php.net/fix.php?id=37676r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=37676r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=37676r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37676r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=37676r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37676r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37676r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=37676r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=37676r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=37676r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37676r=mysqlcfg

#37294 [Asn-Csd]: PHP crashes Apache on PDO::query instead of throwing an exception

2006-05-08 Thread tgross at m-s dot de 
 ID:   37294
 User updated by:  tgross at m-s dot de
 Reported By:  tgross at m-s dot de
-Status:   Assigned
+Status:   Closed
 Bug Type: PDO related
 Operating System: Windows 2000
 PHP Version:  5.1.3
 Assigned To:  wez
 New Comment:

This is fixed in 5.1.4


Previous Comments:


[2006-05-04 02:12:49] thad at bronto dot com

I see this exact behavior using apache 2.0.55 on Centos 
4.2 with php 5.1.3.



[2006-05-03 14:58:41] tgross at m-s dot de

Description:

When calling PDO::query(), PHP crashes Apache on certain queries if the
SQL-query contains errors.

In the example, Query 1 is correct.
Query 2 is wrong, and the exception is thrown (which is expected).
Query 3 causes Apache to crash.

Reproduce code:
---
$dbh = new PDO ('odbc:DRIVER={Microsoft Access Driver
(*.mdb)};DBQ=c:/path/to/database/db.mdb', '', '');
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

try
{
//$result = $dbh-query('select * from aktuelles');   //  Query 1:
Correct
//$result = $dbh-query('select * from aktuellesX');  //  Query 2:
Wrong (Table aktuellesX does not exist)
  $result = $dbh-query('selectX * from aktuelles');  //  Query 3:
Wrong (Command selectX does not exist)
  $ret = $result-fetchAll(PDO::FETCH_ASSOC);
}
catch (Exception $e)
{
  echo Failed:  , $e-getMessage();
}


Expected result:

PHP throws an exception and displays the error message.

Actual result:
--
Apache crashes.





-- 
Edit this bug report at http://bugs.php.net/?id=37294edit=1

#37294 [NEW]: PHP crashes Apache on PDO::query instead of throwing an exception

2006-05-03 Thread tgross at m-s dot de 
From: tgross at m-s dot de
Operating system: Windows 2000
PHP version:  5.1.3
PHP Bug Type: PDO related
Bug description:  PHP crashes Apache on PDO::query instead of throwing an 
exception

Description:

When calling PDO::query(), PHP crashes Apache on certain queries if the
SQL-query contains errors.

In the example, Query 1 is correct.
Query 2 is wrong, and the exception is thrown (which is expected).
Query 3 causes Apache to crash.

Reproduce code:
---
$dbh = new PDO ('odbc:DRIVER={Microsoft Access Driver
(*.mdb)};DBQ=c:/path/to/database/db.mdb', '', '');
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

try
{
//$result = $dbh-query('select * from aktuelles');   //  Query 1:
Correct
//$result = $dbh-query('select * from aktuellesX');  //  Query 2: Wrong
(Table aktuellesX does not exist)
  $result = $dbh-query('selectX * from aktuelles');  //  Query 3: Wrong
(Command selectX does not exist)
  $ret = $result-fetchAll(PDO::FETCH_ASSOC);
}
catch (Exception $e)
{
  echo Failed:  , $e-getMessage();
}


Expected result:

PHP throws an exception and displays the error message.

Actual result:
--
Apache crashes.

-- 
Edit bug report at http://bugs.php.net/?id=37294edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=37294r=trysnapshot44
Try a CVS snapshot (PHP 5.1): 
http://bugs.php.net/fix.php?id=37294r=trysnapshot51
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=37294r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37294r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=37294r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=37294r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37294r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37294r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=37294r=support
Expected behavior:http://bugs.php.net/fix.php?id=37294r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=37294r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=37294r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37294r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=37294r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37294r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37294r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=37294r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=37294r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=37294r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37294r=mysqlcfg