[PHP-BUG] Bug #65311 [NEW]: testsuite failure due to incomplete fix to bug28985.phpt

2013-07-22 Thread hsk at fli-leibniz dot de
From: hsk at fli-leibniz dot de
Operating system: 
PHP version:  5.5.1
Package:  *General Issues
Bug Type: Bug
Bug description:testsuite failure due to incomplete fix to bug28985.phpt

Description:

test ext/soap/tests/bugs/bug28985.phpt fails in 5.5.1

for 5.5.1, there is a typo fix in line 50 (Defaut -- Default), but in line
47, the length of the resulting string is still given as 86, which must now
be 87


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



Bug #53597 [Csd]: open_basedir not working as documented

2011-02-10 Thread hsk at fli-leibniz dot de
Edit report at http://bugs.php.net/bug.php?id=53597edit=1

 ID: 53597
 User updated by:hsk at fli-leibniz dot de
 Reported by:hsk at fli-leibniz dot de
 Summary:open_basedir not working as documented
 Status: Closed
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Linux
 PHP Version:5.3.4
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

ahhh, a bug once documented is a feature :-)



please reopen this case



it's not the documentation that should be changed but the php code so
that php again has the behaviour it had ever since



as things are now they introduce an incompatible change to php: the
setting open_basedir=/u/phpMyAdmin no longer allows to access e.g.
/u/phpMyAdmin-3.3.9-all-languages/index.php



maybe
http://svn.php.net/viewvc/php/php-src/trunk/main/fopen_wrappers.c?r1=305098r2=305698
causes the problems described?


Previous Comments:

[2011-02-10 16:58:08] vr...@php.net

Automatic comment from SVN on behalf of vrana
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=308212
Log: open_basedir is not prefix anymore (doc bug #53597)


[2011-02-10 16:58:07] vr...@php.net

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.




[2011-01-12 17:25:07] chroom dot chroom at gmail dot com

1  I confirm: open_basedir does not act as prefix



I experience the same problem with an earlier version: PHP 5.3.2 (API
20090626) on 32-bit Ubuntu 10.04.



2  A new case: open_basedir ending with a slash blocks PHP



Another problem with the same config option is: path ending with a slash
practically blocks PHP in an annoying way. With open_basedir set to
/var/www/ it is expected to be able to serve files from this
directory, but it doesn't work. This is not only different from the
docs, this is nonsense. It's the behaviour that should be changed, not
only the docs. So please change the bug status.

This excerpt from errorlog documents this absurd:



PHP Warning:  Unknown: open_basedir restriction in effect. File(/var/

www/bits.php) is not within the allowed path(s): (/var/www/) in Unknown
on line 0


[2011-01-10 16:31:14] paj...@php.net

Docs need to be updated but that won't change.


[2011-01-10 16:31:11] paj...@php.net

Docs need to be updated but that won't change.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=53597


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


Bug #53597 [Dup]: open_basedir not working as documented

2011-01-10 Thread hsk at fli-leibniz dot de
Edit report at http://bugs.php.net/bug.php?id=53597edit=1

 ID: 53597
 User updated by:hsk at fli-leibniz dot de
 Reported by:hsk at fli-leibniz dot de
 Summary:open_basedir not working as documented
 Status: Duplicate
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Linux
 PHP Version:5.3.4
 Block user comment: N
 Private report: N

 New Comment:

#53597 is definitely *not* a duplicate of #53577, please change status



open_basedir as of 5.3.4 (and 5.3.5 as well) no longer allows to specify
directory prefixes, in contradiction to the documentation



e.g., setting

  open_basedir = /u/phpMyAdmin

should accept files in /u/phpMyAdmin-3.3.8.1-all-languages, but does not


Previous Comments:

[2010-12-24 05:29:41] ahar...@php.net

Duplicate of bug #53577.


[2010-12-23 12:38:27] hsk at fli-leibniz dot de

Description:

the php manual in the section Description of core php.ini directives

(http://www.php.net/manual/en/ini.core.php, checked on 23-dec-10 11:55
utc)

states:



The restriction specified with open_basedir is actually a prefix, not a

directory name.



this has been so ever since, but seems now broken at release 5.3.4 -

specifying directory name prefix gives access denied errors, only
specifying complete directory name seems to work.



if the described behaviour is intentional, please fix the documentation
*and note the change in BIG BOLD LETTERS in the release announcement*,
or, better, fix the php-code to behave as documented.

Test script:
---
phpmyadmin installed and configured in
/u/phpMyAdmin-3.3.8.1-all-languages



entry in /usr/lib/php.ini :



open_basedir = /tmp/:/u/phpMyAdmin:/usr/lib/php/



according to the documentation, this should give access to the
phpmyadmin installation, and used to do so up to php-5.3.3, but now, as
of php-5.3.4, gives an error message

open_basedir restriction in effect.
File(/u/phpMyAdmin-3.3.8.1-all-languages/index.php) is not within the
allowed path(s): (/tmp/:/u/phpMyAdmin:/usr/lib/php/)



it works when changing /usr/lib/php.ini to 

open_basedir = /tmp/:/u/phpMyAdmin-3.3.8.1-all-languages:/usr/lib/php/







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


[PHP-BUG] Bug #53597 [NEW]: open_basedir not working as documented

2010-12-23 Thread hsk at fli-leibniz dot de
From: 
Operating system: Linux
PHP version:  5.3.4
Package:  *Directory/Filesystem functions
Bug Type: Bug
Bug description:open_basedir not working as documented

Description:

the php manual in the section Description of core php.ini directives

(http://www.php.net/manual/en/ini.core.php, checked on 23-dec-10 11:55
utc)

states:



The restriction specified with open_basedir is actually a prefix, not a

directory name.



this has been so ever since, but seems now broken at release 5.3.4 -

specifying directory name prefix gives access denied errors, only
specifying complete directory name seems to work.



if the described behaviour is intentional, please fix the documentation
*and note the change in BIG BOLD LETTERS in the release announcement*, or,
better, fix the php-code to behave as documented.

Test script:
---
phpmyadmin installed and configured in /u/phpMyAdmin-3.3.8.1-all-languages



entry in /usr/lib/php.ini :



open_basedir = /tmp/:/u/phpMyAdmin:/usr/lib/php/



according to the documentation, this should give access to the phpmyadmin
installation, and used to do so up to php-5.3.3, but now, as of php-5.3.4,
gives an error message

open_basedir restriction in effect.
File(/u/phpMyAdmin-3.3.8.1-all-languages/index.php) is not within the
allowed path(s): (/tmp/:/u/phpMyAdmin:/usr/lib/php/)



it works when changing /usr/lib/php.ini to 

open_basedir = /tmp/:/u/phpMyAdmin-3.3.8.1-all-languages:/usr/lib/php/


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