[PHP-BUG] Bug #53634 [NEW]: unknown property when writing to DateInterval::$days

[danielc at analysisandsolutions dot com]

From: 
Operating system: linux
PHP version:  5.3SVN-2010-12-30 (SVN)
Package:  Date/time related
Bug Type: Bug
Bug description:unknown property when writing to DateInterval::$days

Description:

One can not set the DateInterval::$days property.  It is readable.  All
other properties of DateInterval shown in var_dump() are writeable.



While similar to Bug #52738, this involves an actual property of the
DateInterval class.



Test script:
---
$i = new DateInterval('P1D');

$i-s = 8;

echo S: $i-s\n;

echo DAYS: $i-days\n;

$i-days = 6;

echo DAYS: $i-days\n;



Expected result:

S: 8

DAYS: -9

DAYS: 6



Actual result:
--
S: 8

DAYS: -9

PHP Fatal error:  main(): Unknown property (days) in /home/danielc/test.php
on line 7



-- 
Edit bug report at http://bugs.php.net/bug.php?id=53634edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53634r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53634r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=53634r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53634r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=53634r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53634r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=53634r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=53634r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=53634r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=53634r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=53634r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=53634r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=53634r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53634r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=53634r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53634r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=53634r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=53634r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=53634r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=53634r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=53634r=mysqlcfg

Bug #53591 [Bgs]: exec() fails to impersonate calling context when fastcgi.impersonate is true

[sbacsa at gmail dot com]

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

 ID: 53591
 User updated by:sbacsa at gmail dot com
 Reported by:sbacsa at gmail dot com
 Summary:exec() fails to impersonate calling context when
 fastcgi.impersonate is true
 Status: Bogus
 Type:   Bug
 Package:IIS related
 Operating System:   Windows Server 2008
 PHP Version:5.3.4
 Block user comment: N
 Private report: N

 New Comment:

I have done all of that, and that was not a solution.



If you disable fastcgi.impersonate, then it will run in the user context
of the 

worker process (whatever you set it to; I set it to a custom user
account), so 

clearly it DOES impersonate the user, but it just does not seem to work
with 

whatever fastcgi.impersonate tries to do.



That being said, this was not an issue in PHP 5.2.x; it worked with 

fastcgi.impersonate and did not cause errors.  All I did was replace the
PHP 

binaries with the new version and configured IIS.  There should be no
reason why 

it should fail.


Previous Comments:

[2010-12-22 01:02:55] paj...@php.net

You have to give FCGI's php handler the permission to execute codes.
Check out the IIS documentation (as far as I remember it is also
documented in the PHP manual, in the IIS configuration part).


[2010-12-22 00:10:41] sbacsa at gmail dot com

Description:

It appears that enabling fastcgi.impersonate on Windows in PHP 5.3.x
does not 

actually impersonate the calling user when using exec() or similar.



I would just get messages saying Cannot fork, whereas in PHP 5.2.x
there was no 

such error.



Turning off fastcgi.impersonate fixed this issue, as IIS seems to run
PHP in the 

user context of the worker process anyway.

Test script:
---
?



// This will fail when fastcgi.impersonate = 1 in PHP 5.3.x

exec(c:\\path\\to\\executable.exe);

Expected result:

The file should be successfully executed if the worker process user has
permission 

to access the EXE.

Actual result:
--
Regardless of worker process permissions, an error message saying:



Warning: exec() [function.exec]: Unable to fork
[c:\path\to\executable.exe]



is encountered.










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