Professional Web Applications Themes

#25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files - PHP Development

ID: 25753 Comment by: mazurek at shw-networks dot de Reported By: [email]sniperphp.net[/email] Status: Critical Bug Type: Apache related Operating System: * PHP Version: 4CVS, 5CVS New Comment: Hi Sniper, do you have any plan, what causes this errors? Do you want me to test the newest RC1? What can I do to help you solving the Problems ? Our customers are getting very unhappy.(because of the open basedir errors). Do you need access to our Systems ? This Bug seems to be very hard to reproduce, because it never appears diretly after an apache restart. Daniel Previous Comments: ------------------------------------------------------------------------ [2003-10-04 ...

  1. #1

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: mazurek at shw-networks dot de
    Reported By: [email]sniperphp.net[/email]
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    Hi Sniper,

    do you have any plan, what causes this errors? Do you want me to test
    the newest RC1?
    What can I do to help you solving the Problems ? Our customers are
    getting very unhappy.(because of the open basedir errors).

    Do you need access to our Systems ? This Bug seems to be very hard to
    reproduce, because it never appears diretly after an apache restart.

    Daniel


    Previous Comments:
    ------------------------------------------------------------------------

    [2003-10-04 00:48:12] [email]sniperphp.net[/email]

    Description:
    ------------
    If (for example) one virtualhost configuration has
    set "php_admin_flag register_globals off", in some situations the
    setting persists between requests.
    -> php.ini settings are NOT reset between requests.

    1. php.ini has register_globals = On
    2. Request is made into [url]www.foobar.com[/url]
    (which has "php_admin_flag register_globals off")
    3. Next request (same apache child) is made into [url]www.barfoo.com[/url] (which
    does not have the setting)

    This applies to ALL php.ini directives.

    Some related reports:

    bug #6374 (include_path in .htaccess across multiple vhosts)
    bug #7174 (Round-robin -like values for include_path)
    bug #19292 (Random error: open_basedir restriction..)
    bug #21564 (corrupted paths coming to open_basedir)
    bug #23462 ("php_admin_value open_basedir" in httpd.conf)
    bug #23580 (Random values for include_path)
    bug #24282 (Strange Open Base Dir Restriction Errors)
    bug #24974 (random open_basedir errors)
    bug #25172 ($HTTP_HOST sometimes empty)

    For all who think they're experiencing this problem:
    DO NOT add any comments here unless you have some extra information to
    give which is not already given in above mentioned reports.
    Any comment which has no extra value will be deleted.




    ------------------------------------------------------------------------


    --
    Edit this bug report at [url]http://bugs.php.net/?id=25753&edit=1[/url]
    mazurek at shw-networks dot de Guest

  2. #2

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: dave at puseyuk dot co dot uk
    Reported By: [email]sniperphp.net[/email]
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    Why not just put

    php_admin_flag register_globals on

    into the [url]www.barfoo.com[/url] directives.


    Previous Comments:
    ------------------------------------------------------------------------

    [2003-10-04 18:58:16] [email]sniperphp.net[/email]

    We do not know what causes this bug or how it can be reliably
    reproduced. If you know exactly HOW this can be reproduced, add the
    information here. Any other comments will be deleted.


    ------------------------------------------------------------------------

    [2003-10-04 00:48:12] [email]sniperphp.net[/email]

    Description:
    ------------
    If (for example) one virtualhost configuration has
    set "php_admin_flag register_globals off", in some situations the
    setting persists between requests.
    -> php.ini settings are NOT reset between requests.

    1. php.ini has register_globals = On
    2. Request is made into [url]www.foobar.com[/url]
    (which has "php_admin_flag register_globals off")
    3. Next request (same apache child) is made into [url]www.barfoo.com[/url] (which
    does not have the setting)

    This applies to ALL php.ini directives.

    Some related reports:

    bug #6374 (include_path in .htaccess across multiple vhosts)
    bug #7174 (Round-robin -like values for include_path)
    bug #19292 (Random error: open_basedir restriction..)
    bug #21564 (corrupted paths coming to open_basedir)
    bug #23462 ("php_admin_value open_basedir" in httpd.conf)
    bug #23580 (Random values for include_path)
    bug #24282 (Strange Open Base Dir Restriction Errors)
    bug #24974 (random open_basedir errors)
    bug #25172 ($HTTP_HOST sometimes empty)

    For all who think they're experiencing this problem:
    DO NOT add any comments here unless you have some extra information to
    give which is not already given in above mentioned reports.
    Any comment which has no extra value will be deleted.




    ------------------------------------------------------------------------


    --
    Edit this bug report at [url]http://bugs.php.net/?id=25753&edit=1[/url]
    dave at puseyuk dot co dot uk Guest

  3. #3

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: mattias at segerdahl dot info
    Reported By: [email]sniperphp.net[/email]
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    Sniper,

    I accidently ran into this bug a few moments ago. I talked to Derick
    about it in the channel and we agreed I would do some testing. There
    are some particular strange behaviour.

    I will try to explain as well as include the files needed to reproduce
    this error. But first let me point out one thing that I find really
    weird.

    This only occurs when the apache server has not been accessed for a
    while, if you reload the page directly after you've encountered this
    error message, it will work perfectly.

    The error message is:

    Warning: Unknown(): open_basedir restriction in effect.
    File(/var/www/users.bitcom.se/index.php) is not within the allowed
    path(s): (/var/www/www.sol.se) in Unknown on line 0
    Warning: Unknown(/var/www/users.bitcom.se/index.php): failed to open
    stream: Operation not permitted in Unknown on line 0
    Warning: (null)(): Failed opening '/var/www/users.bitcom.se/index.php'
    for inclusion (include_path='.:/usr/local/php//lib/php') in Unknown on
    line 0

    My php.ini file [url]http://www.segerdahl.info/25753/php.ini[/url]
    My httpd.conf file [url]http://www.segerdahl.info/25753/httpd.conf[/url]

    Server version: Apache/2.0.47
    Server built: Oct 20 2003 18:39:21

    PHP 4.3.4RC4 configured as:

    './configure' '--with-apxs2=/usr/local/httpd/bin/apxs'
    '--enable-mbstring' '--with-pear' '--with-mysql'
    '--enable-magic-quotes' '--with-ftp' '--sysconfdir=/etc/php'
    '--with-config-file-path=/etc/php' '--prefix=/usr/local/php/'
    '--enable-mbstring' '--with-curl' '--enable-ftp'

    APACHE configured as:
    ../configure --sysconfdir=/etc/httpd/conf --enable-ssl
    --prefix=/usr/local/httpd --enable-modules=dso,most

    Contact me on efnet if you need more information... // bad2da


    Previous Comments:
    ------------------------------------------------------------------------

    [2003-10-04 18:58:16] [email]sniperphp.net[/email]

    We do not know what causes this bug or how it can be reliably
    reproduced. If you know exactly HOW this can be reproduced, add the
    information here. Any other comments will be deleted.


    ------------------------------------------------------------------------

    [2003-10-04 00:48:12] [email]sniperphp.net[/email]

    Description:
    ------------
    If (for example) one virtualhost configuration has
    set "php_admin_flag register_globals off", in some situations the
    setting persists between requests.
    -> php.ini settings are NOT reset between requests.

    1. php.ini has register_globals = On
    2. Request is made into [url]www.foobar.com[/url]
    (which has "php_admin_flag register_globals off")
    3. Next request (same apache child) is made into [url]www.barfoo.com[/url] (which
    does not have the setting)

    This applies to ALL php.ini directives.

    Some related reports:

    bug #6374 (include_path in .htaccess across multiple vhosts)
    bug #7174 (Round-robin -like values for include_path)
    bug #19292 (Random error: open_basedir restriction..)
    bug #21564 (corrupted paths coming to open_basedir)
    bug #23462 ("php_admin_value open_basedir" in httpd.conf)
    bug #23580 (Random values for include_path)
    bug #24282 (Strange Open Base Dir Restriction Errors)
    bug #24974 (random open_basedir errors)
    bug #25172 ($HTTP_HOST sometimes empty)

    For all who think they're experiencing this problem:
    DO NOT add any comments here unless you have some extra information to
    give which is not already given in above mentioned reports.
    Any comment which has no extra value will be deleted.




    ------------------------------------------------------------------------


    --
    Edit this bug report at [url]http://bugs.php.net/?id=25753&edit=1[/url]
    mattias at segerdahl dot info Guest

  4. #4

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: clemmon at eventerra dot com
    Reported By: [email]sniperphp.net[/email]
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    I'm not sure if I am on to something or not, so I will pass this info
    on to those that obviously know more than me. I am getting the
    "open_basedir restriction in effect" in Moregroupware. It appears that
    the error consistantly appears at lines with the following;
    "require('mime_mapping.php')". These calls appear in packages
    horde.mime and horde.mime.viewer. The rest of Moregroupware appears to
    function without issue. I hope this helps and does not clutter the
    issue.


    Previous Comments:
    ------------------------------------------------------------------------

    [2003-10-22 04:01:39] mattias at segerdahl dot info

    Sniper,

    I accidently ran into this bug a few moments ago. I talked to Derick
    about it in the channel and we agreed I would do some testing. There
    are some particular strange behaviour.

    I will try to explain as well as include the files needed to reproduce
    this error. But first let me point out one thing that I find really
    weird.

    This only occurs when the apache server has not been accessed for a
    while, if you reload the page directly after you've encountered this
    error message, it will work perfectly.

    The error message is:

    Warning: Unknown(): open_basedir restriction in effect.
    File(/var/www/users.bitcom.se/index.php) is not within the allowed
    path(s): (/var/www/www.sol.se) in Unknown on line 0
    Warning: Unknown(/var/www/users.bitcom.se/index.php): failed to open
    stream: Operation not permitted in Unknown on line 0
    Warning: (null)(): Failed opening '/var/www/users.bitcom.se/index.php'
    for inclusion (include_path='.:/usr/local/php//lib/php') in Unknown on
    line 0

    My php.ini file [url]http://www.segerdahl.info/25753/php.ini[/url]
    My httpd.conf file [url]http://www.segerdahl.info/25753/httpd.conf[/url]

    Server version: Apache/2.0.47
    Server built: Oct 20 2003 18:39:21

    PHP 4.3.4RC4 configured as:

    './configure' '--with-apxs2=/usr/local/httpd/bin/apxs'
    '--enable-mbstring' '--with-pear' '--with-mysql'
    '--enable-magic-quotes' '--with-ftp' '--sysconfdir=/etc/php'
    '--with-config-file-path=/etc/php' '--prefix=/usr/local/php/'
    '--enable-mbstring' '--with-curl' '--enable-ftp'

    APACHE configured as:
    ../configure --sysconfdir=/etc/httpd/conf --enable-ssl
    --prefix=/usr/local/httpd --enable-modules=dso,most

    Contact me on efnet if you need more information... // bad2da

    ------------------------------------------------------------------------

    [2003-10-04 18:58:16] [email]sniperphp.net[/email]

    We do not know what causes this bug or how it can be reliably
    reproduced. If you know exactly HOW this can be reproduced, add the
    information here. Any other comments will be deleted.


    ------------------------------------------------------------------------

    [2003-10-04 00:48:12] [email]sniperphp.net[/email]

    Description:
    ------------
    If (for example) one virtualhost configuration has
    set "php_admin_flag register_globals off", in some situations the
    setting persists between requests.
    -> php.ini settings are NOT reset between requests.

    1. php.ini has register_globals = On
    2. Request is made into [url]www.foobar.com[/url]
    (which has "php_admin_flag register_globals off")
    3. Next request (same apache child) is made into [url]www.barfoo.com[/url] (which
    does not have the setting)

    This applies to ALL php.ini directives.

    Some related reports:

    bug #6374 (include_path in .htaccess across multiple vhosts)
    bug #7174 (Round-robin -like values for include_path)
    bug #19292 (Random error: open_basedir restriction..)
    bug #21564 (corrupted paths coming to open_basedir)
    bug #23462 ("php_admin_value open_basedir" in httpd.conf)
    bug #23580 (Random values for include_path)
    bug #24282 (Strange Open Base Dir Restriction Errors)
    bug #24974 (random open_basedir errors)
    bug #25172 ($HTTP_HOST sometimes empty)

    For all who think they're experiencing this problem:
    DO NOT add any comments here unless you have some extra information to
    give which is not already given in above mentioned reports.
    Any comment which has no extra value will be deleted.




    ------------------------------------------------------------------------


    --
    Edit this bug report at [url]http://bugs.php.net/?id=25753&edit=1[/url]
    clemmon at eventerra dot com Guest

  5. #5

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: thorv at tiscali dot no
    Reported By: [email]sniperphp.net[/email]
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    One virtual server (without .htaccess) sometimes gives this warning:
    ---
    PHP Warning: head(): Failed opening 'themes/theme.php' for inclusion
    (include_path='/first/path:/second/path') in /header.php on line 31
    ---
    The path for this virtual server should have been the php.ini path
    (include_path = ".:/usr/lib/php/"), but obviously another virtual
    server has 'leaked' a local path.

    The content of the "offending" virtual hosts .htaccess file is:
    php_value include_path "/first/path:/second/path"
    php_flag register_globals off

    I can sometimes (but not reliably) reproduce the error by accessing the
    "offending" virtual host a few times, and then access the site that
    gives the error message.

    Have had no problems prior to Apache 2.0.47 (reported bug#24120), PHP
    4.3.3 on Mandrake 9.2.


    Previous Comments:
    ------------------------------------------------------------------------

    [2003-10-24 22:46:18] clemmon at eventerra dot com

    I'm not sure if I am on to something or not, so I will pass this info
    on to those that obviously know more than me. I am getting the
    "open_basedir restriction in effect" in Moregroupware. It appears that
    the error consistantly appears at lines with the following;
    "require('mime_mapping.php')". These calls appear in packages
    horde.mime and horde.mime.viewer. The rest of Moregroupware appears to
    function without issue. I hope this helps and does not clutter the
    issue.

    ------------------------------------------------------------------------

    [2003-10-22 04:01:39] mattias at segerdahl dot info

    Sniper,

    I accidently ran into this bug a few moments ago. I talked to Derick
    about it in the channel and we agreed I would do some testing. There
    are some particular strange behaviour.

    I will try to explain as well as include the files needed to reproduce
    this error. But first let me point out one thing that I find really
    weird.

    This only occurs when the apache server has not been accessed for a
    while, if you reload the page directly after you've encountered this
    error message, it will work perfectly.

    The error message is:

    Warning: Unknown(): open_basedir restriction in effect.
    File(/var/www/users.bitcom.se/index.php) is not within the allowed
    path(s): (/var/www/www.sol.se) in Unknown on line 0
    Warning: Unknown(/var/www/users.bitcom.se/index.php): failed to open
    stream: Operation not permitted in Unknown on line 0
    Warning: (null)(): Failed opening '/var/www/users.bitcom.se/index.php'
    for inclusion (include_path='.:/usr/local/php//lib/php') in Unknown on
    line 0

    My php.ini file [url]http://www.segerdahl.info/25753/php.ini[/url]
    My httpd.conf file [url]http://www.segerdahl.info/25753/httpd.conf[/url]

    Server version: Apache/2.0.47
    Server built: Oct 20 2003 18:39:21

    PHP 4.3.4RC4 configured as:

    './configure' '--with-apxs2=/usr/local/httpd/bin/apxs'
    '--enable-mbstring' '--with-pear' '--with-mysql'
    '--enable-magic-quotes' '--with-ftp' '--sysconfdir=/etc/php'
    '--with-config-file-path=/etc/php' '--prefix=/usr/local/php/'
    '--enable-mbstring' '--with-curl' '--enable-ftp'

    APACHE configured as:
    ../configure --sysconfdir=/etc/httpd/conf --enable-ssl
    --prefix=/usr/local/httpd --enable-modules=dso,most

    Contact me on efnet if you need more information... // bad2da

    ------------------------------------------------------------------------

    [2003-10-04 18:58:16] [email]sniperphp.net[/email]

    We do not know what causes this bug or how it can be reliably
    reproduced. If you know exactly HOW this can be reproduced, add the
    information here. Any other comments will be deleted.


    ------------------------------------------------------------------------

    [2003-10-04 00:48:12] [email]sniperphp.net[/email]

    Description:
    ------------
    If (for example) one virtualhost configuration has
    set "php_admin_flag register_globals off", in some situations the
    setting persists between requests.
    -> php.ini settings are NOT reset between requests.

    1. php.ini has register_globals = On
    2. Request is made into [url]www.foobar.com[/url]
    (which has "php_admin_flag register_globals off")
    3. Next request (same apache child) is made into [url]www.barfoo.com[/url] (which
    does not have the setting)

    This applies to ALL php.ini directives.

    Some related reports:

    bug #6374 (include_path in .htaccess across multiple vhosts)
    bug #7174 (Round-robin -like values for include_path)
    bug #19292 (Random error: open_basedir restriction..)
    bug #21564 (corrupted paths coming to open_basedir)
    bug #23462 ("php_admin_value open_basedir" in httpd.conf)
    bug #23580 (Random values for include_path)
    bug #24282 (Strange Open Base Dir Restriction Errors)
    bug #24974 (random open_basedir errors)
    bug #25172 ($HTTP_HOST sometimes empty)

    For all who think they're experiencing this problem:
    DO NOT add any comments here unless you have some extra information to
    give which is not already given in above mentioned reports.
    Any comment which has no extra value will be deleted.




    ------------------------------------------------------------------------


    --
    Edit this bug report at [url]http://bugs.php.net/?id=25753&edit=1[/url]
    thorv at tiscali dot no Guest

  6. #6

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: mattias at segerdahl dot info
    Reported By: [email]sniperphp.net[/email]
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    This bug only appears when and if you have overlapping virtualhosts in
    apache2. Using fqdn's that have IN A or CNAME to an ipaddress on the
    server seems to fix it.

    This is only an observation that seems to have gotten rid of the
    problem for me.

    // bad2da


    Previous Comments:
    ------------------------------------------------------------------------

    [2003-10-26 09:58:23] thorv at tiscali dot no

    One virtual server (without .htaccess) sometimes gives this warning:
    ---
    PHP Warning: head(): Failed opening 'themes/theme.php' for inclusion
    (include_path='/first/path:/second/path') in /header.php on line 31
    ---
    The path for this virtual server should have been the php.ini path
    (include_path = ".:/usr/lib/php/"), but obviously another virtual
    server has 'leaked' a local path.

    The content of the "offending" virtual hosts .htaccess file is:
    php_value include_path "/first/path:/second/path"
    php_flag register_globals off

    I can sometimes (but not reliably) reproduce the error by accessing the
    "offending" virtual host a few times, and then access the site that
    gives the error message.

    Have had no problems prior to Apache 2.0.47 (reported bug#24120), PHP
    4.3.3 on Mandrake 9.2.

    ------------------------------------------------------------------------

    [2003-10-22 04:01:39] mattias at segerdahl dot info

    Sniper,

    I accidently ran into this bug a few moments ago. I talked to Derick
    about it in the channel and we agreed I would do some testing. There
    are some particular strange behaviour.

    I will try to explain as well as include the files needed to reproduce
    this error. But first let me point out one thing that I find really
    weird.

    This only occurs when the apache server has not been accessed for a
    while, if you reload the page directly after you've encountered this
    error message, it will work perfectly.

    The error message is:

    Warning: Unknown(): open_basedir restriction in effect.
    File(/var/www/users.bitcom.se/index.php) is not within the allowed
    path(s): (/var/www/www.sol.se) in Unknown on line 0
    Warning: Unknown(/var/www/users.bitcom.se/index.php): failed to open
    stream: Operation not permitted in Unknown on line 0
    Warning: (null)(): Failed opening '/var/www/users.bitcom.se/index.php'
    for inclusion (include_path='.:/usr/local/php//lib/php') in Unknown on
    line 0

    My php.ini file [url]http://www.segerdahl.info/25753/php.ini[/url]
    My httpd.conf file [url]http://www.segerdahl.info/25753/httpd.conf[/url]

    Server version: Apache/2.0.47
    Server built: Oct 20 2003 18:39:21

    PHP 4.3.4RC4 configured as:

    './configure' '--with-apxs2=/usr/local/httpd/bin/apxs'
    '--enable-mbstring' '--with-pear' '--with-mysql'
    '--enable-magic-quotes' '--with-ftp' '--sysconfdir=/etc/php'
    '--with-config-file-path=/etc/php' '--prefix=/usr/local/php/'
    '--enable-mbstring' '--with-curl' '--enable-ftp'

    APACHE configured as:
    ../configure --sysconfdir=/etc/httpd/conf --enable-ssl
    --prefix=/usr/local/httpd --enable-modules=dso,most

    Contact me on efnet if you need more information... // bad2da

    ------------------------------------------------------------------------

    [2003-10-04 18:58:16] [email]sniperphp.net[/email]

    We do not know what causes this bug or how it can be reliably
    reproduced. If you know exactly HOW this can be reproduced, add the
    information here. Any other comments will be deleted.


    ------------------------------------------------------------------------

    [2003-10-04 00:48:12] [email]sniperphp.net[/email]

    Description:
    ------------
    If (for example) one virtualhost configuration has
    set "php_admin_flag register_globals off", in some situations the
    setting persists between requests.
    -> php.ini settings are NOT reset between requests.

    1. php.ini has register_globals = On
    2. Request is made into [url]www.foobar.com[/url]
    (which has "php_admin_flag register_globals off")
    3. Next request (same apache child) is made into [url]www.barfoo.com[/url] (which
    does not have the setting)

    This applies to ALL php.ini directives.

    Some related reports:

    bug #6374 (include_path in .htaccess across multiple vhosts)
    bug #7174 (Round-robin -like values for include_path)
    bug #19292 (Random error: open_basedir restriction..)
    bug #21564 (corrupted paths coming to open_basedir)
    bug #23462 ("php_admin_value open_basedir" in httpd.conf)
    bug #23580 (Random values for include_path)
    bug #24282 (Strange Open Base Dir Restriction Errors)
    bug #24974 (random open_basedir errors)
    bug #25172 ($HTTP_HOST sometimes empty)

    For all who think they're experiencing this problem:
    DO NOT add any comments here unless you have some extra information to
    give which is not already given in above mentioned reports.
    Any comment which has no extra value will be deleted.




    ------------------------------------------------------------------------


    --
    Edit this bug report at [url]http://bugs.php.net/?id=25753&edit=1[/url]
    mattias at segerdahl dot info Guest

  7. #7

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: fs at nessus dot at
    Reported By: [email]sniperphp.net[/email]
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    no thats false.
    this bug occours on apache 1.3.x too (tested it with 1.3.27).
    i think thats very essential...

    greetings,

    Florian Schicker
    [url]www.nessus.at[/url]


    Previous Comments:
    ------------------------------------------------------------------------

    [2003-10-28 04:13:33] mattias at segerdahl dot info

    This bug only appears when and if you have overlapping virtualhosts in
    apache2. Using fqdn's that have IN A or CNAME to an ipaddress on the
    server seems to fix it.

    This is only an observation that seems to have gotten rid of the
    problem for me.

    // bad2da

    ------------------------------------------------------------------------

    [2003-10-22 04:01:39] mattias at segerdahl dot info

    Sniper,

    I accidently ran into this bug a few moments ago. I talked to Derick
    about it in the channel and we agreed I would do some testing. There
    are some particular strange behaviour.

    I will try to explain as well as include the files needed to reproduce
    this error. But first let me point out one thing that I find really
    weird.

    This only occurs when the apache server has not been accessed for a
    while, if you reload the page directly after you've encountered this
    error message, it will work perfectly.

    The error message is:

    Warning: Unknown(): open_basedir restriction in effect.
    File(/var/www/users.bitcom.se/index.php) is not within the allowed
    path(s): (/var/www/www.sol.se) in Unknown on line 0
    Warning: Unknown(/var/www/users.bitcom.se/index.php): failed to open
    stream: Operation not permitted in Unknown on line 0
    Warning: (null)(): Failed opening '/var/www/users.bitcom.se/index.php'
    for inclusion (include_path='.:/usr/local/php//lib/php') in Unknown on
    line 0

    My php.ini file [url]http://www.segerdahl.info/25753/php.ini[/url]
    My httpd.conf file [url]http://www.segerdahl.info/25753/httpd.conf[/url]

    Server version: Apache/2.0.47
    Server built: Oct 20 2003 18:39:21

    PHP 4.3.4RC4 configured as:

    './configure' '--with-apxs2=/usr/local/httpd/bin/apxs'
    '--enable-mbstring' '--with-pear' '--with-mysql'
    '--enable-magic-quotes' '--with-ftp' '--sysconfdir=/etc/php'
    '--with-config-file-path=/etc/php' '--prefix=/usr/local/php/'
    '--enable-mbstring' '--with-curl' '--enable-ftp'

    APACHE configured as:
    ../configure --sysconfdir=/etc/httpd/conf --enable-ssl
    --prefix=/usr/local/httpd --enable-modules=dso,most

    Contact me on efnet if you need more information... // bad2da

    ------------------------------------------------------------------------

    [2003-10-04 18:58:16] [email]sniperphp.net[/email]

    We do not know what causes this bug or how it can be reliably
    reproduced. If you know exactly HOW this can be reproduced, add the
    information here. Any other comments will be deleted.


    ------------------------------------------------------------------------

    [2003-10-04 00:48:12] [email]sniperphp.net[/email]

    Description:
    ------------
    If (for example) one virtualhost configuration has
    set "php_admin_flag register_globals off", in some situations the
    setting persists between requests.
    -> php.ini settings are NOT reset between requests.

    1. php.ini has register_globals = On
    2. Request is made into [url]www.foobar.com[/url]
    (which has "php_admin_flag register_globals off")
    3. Next request (same apache child) is made into [url]www.barfoo.com[/url] (which
    does not have the setting)

    This applies to ALL php.ini directives.

    Some related reports:

    bug #6374 (include_path in .htaccess across multiple vhosts)
    bug #7174 (Round-robin -like values for include_path)
    bug #19292 (Random error: open_basedir restriction..)
    bug #21564 (corrupted paths coming to open_basedir)
    bug #23462 ("php_admin_value open_basedir" in httpd.conf)
    bug #23580 (Random values for include_path)
    bug #24282 (Strange Open Base Dir Restriction Errors)
    bug #24974 (random open_basedir errors)
    bug #25172 ($HTTP_HOST sometimes empty)

    For all who think they're experiencing this problem:
    DO NOT add any comments here unless you have some extra information to
    give which is not already given in above mentioned reports.
    Any comment which has no extra value will be deleted.




    ------------------------------------------------------------------------


    --
    Edit this bug report at [url]http://bugs.php.net/?id=25753&edit=1[/url]
    fs at nessus dot at Guest

  8. #8

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: butch at infowest dot com
    Reported By: [email]sniperphp.net[/email]
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    For me, I ended up downgrading to 4.3.1 and that seemed to resolve my
    issues. Must be something that changed after 4.3.1 which is causing the
    issues.


    Previous Comments:
    ------------------------------------------------------------------------

    [2003-10-30 09:35:44] fs at nessus dot at

    no thats false.
    this bug occours on apache 1.3.x too (tested it with 1.3.27).
    i think thats very essential...

    greetings,

    Florian Schicker
    [url]www.nessus.at[/url]

    ------------------------------------------------------------------------

    [2003-10-28 04:13:33] mattias at segerdahl dot info

    This bug only appears when and if you have overlapping virtualhosts in
    apache2. Using fqdn's that have IN A or CNAME to an ipaddress on the
    server seems to fix it.

    This is only an observation that seems to have gotten rid of the
    problem for me.

    // bad2da

    ------------------------------------------------------------------------

    [2003-10-22 04:01:39] mattias at segerdahl dot info

    Sniper,

    I accidently ran into this bug a few moments ago. I talked to Derick
    about it in the channel and we agreed I would do some testing. There
    are some particular strange behaviour.

    I will try to explain as well as include the files needed to reproduce
    this error. But first let me point out one thing that I find really
    weird.

    This only occurs when the apache server has not been accessed for a
    while, if you reload the page directly after you've encountered this
    error message, it will work perfectly.

    The error message is:

    Warning: Unknown(): open_basedir restriction in effect.
    File(/var/www/users.bitcom.se/index.php) is not within the allowed
    path(s): (/var/www/www.sol.se) in Unknown on line 0
    Warning: Unknown(/var/www/users.bitcom.se/index.php): failed to open
    stream: Operation not permitted in Unknown on line 0
    Warning: (null)(): Failed opening '/var/www/users.bitcom.se/index.php'
    for inclusion (include_path='.:/usr/local/php//lib/php') in Unknown on
    line 0

    My php.ini file [url]http://www.segerdahl.info/25753/php.ini[/url]
    My httpd.conf file [url]http://www.segerdahl.info/25753/httpd.conf[/url]

    Server version: Apache/2.0.47
    Server built: Oct 20 2003 18:39:21

    PHP 4.3.4RC4 configured as:

    './configure' '--with-apxs2=/usr/local/httpd/bin/apxs'
    '--enable-mbstring' '--with-pear' '--with-mysql'
    '--enable-magic-quotes' '--with-ftp' '--sysconfdir=/etc/php'
    '--with-config-file-path=/etc/php' '--prefix=/usr/local/php/'
    '--enable-mbstring' '--with-curl' '--enable-ftp'

    APACHE configured as:
    ../configure --sysconfdir=/etc/httpd/conf --enable-ssl
    --prefix=/usr/local/httpd --enable-modules=dso,most

    Contact me on efnet if you need more information... // bad2da

    ------------------------------------------------------------------------

    [2003-10-04 18:58:16] [email]sniperphp.net[/email]

    We do not know what causes this bug or how it can be reliably
    reproduced. If you know exactly HOW this can be reproduced, add the
    information here. Any other comments will be deleted.


    ------------------------------------------------------------------------

    [2003-10-04 00:48:12] [email]sniperphp.net[/email]

    Description:
    ------------
    If (for example) one virtualhost configuration has
    set "php_admin_flag register_globals off", in some situations the
    setting persists between requests.
    -> php.ini settings are NOT reset between requests.

    1. php.ini has register_globals = On
    2. Request is made into [url]www.foobar.com[/url]
    (which has "php_admin_flag register_globals off")
    3. Next request (same apache child) is made into [url]www.barfoo.com[/url] (which
    does not have the setting)

    This applies to ALL php.ini directives.

    Some related reports:

    bug #6374 (include_path in .htaccess across multiple vhosts)
    bug #7174 (Round-robin -like values for include_path)
    bug #19292 (Random error: open_basedir restriction..)
    bug #21564 (corrupted paths coming to open_basedir)
    bug #23462 ("php_admin_value open_basedir" in httpd.conf)
    bug #23580 (Random values for include_path)
    bug #24282 (Strange Open Base Dir Restriction Errors)
    bug #24974 (random open_basedir errors)
    bug #25172 ($HTTP_HOST sometimes empty)

    For all who think they're experiencing this problem:
    DO NOT add any comments here unless you have some extra information to
    give which is not already given in above mentioned reports.
    Any comment which has no extra value will be deleted.




    ------------------------------------------------------------------------


    --
    Edit this bug report at [url]http://bugs.php.net/?id=25753&edit=1[/url]
    butch at infowest dot com Guest

  9. #9

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: simon at implix dot com
    Reported By: [email]sniperphp.net[/email]
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    We have a similar problem.

    We've got overlapping virtualhosts (as they
    are required for one of our application)
    and sometimes PHP returns register_globals = Off,
    even though = On is set in php.ini.

    We are using php 4.3.4 + apache 2.0.48.

    The problem doesn't exist when we use
    php 4.3.1.


    Previous Comments:
    ------------------------------------------------------------------------

    [2003-10-30 09:35:44] fs at nessus dot at

    no thats false.
    this bug occours on apache 1.3.x too (tested it with 1.3.27).
    i think thats very essential...

    greetings,

    Florian Schicker
    [url]www.nessus.at[/url]

    ------------------------------------------------------------------------

    [2003-10-28 04:13:33] mattias at segerdahl dot info

    This bug only appears when and if you have overlapping virtualhosts in
    apache2. Using fqdn's that have IN A or CNAME to an ipaddress on the
    server seems to fix it.

    This is only an observation that seems to have gotten rid of the
    problem for me.

    // bad2da

    ------------------------------------------------------------------------

    [2003-10-22 04:01:39] mattias at segerdahl dot info

    Sniper,

    I accidently ran into this bug a few moments ago. I talked to Derick
    about it in the channel and we agreed I would do some testing. There
    are some particular strange behaviour.

    I will try to explain as well as include the files needed to reproduce
    this error. But first let me point out one thing that I find really
    weird.

    This only occurs when the apache server has not been accessed for a
    while, if you reload the page directly after you've encountered this
    error message, it will work perfectly.

    The error message is:

    Warning: Unknown(): open_basedir restriction in effect.
    File(/var/www/users.bitcom.se/index.php) is not within the allowed
    path(s): (/var/www/www.sol.se) in Unknown on line 0
    Warning: Unknown(/var/www/users.bitcom.se/index.php): failed to open
    stream: Operation not permitted in Unknown on line 0
    Warning: (null)(): Failed opening '/var/www/users.bitcom.se/index.php'
    for inclusion (include_path='.:/usr/local/php//lib/php') in Unknown on
    line 0

    My php.ini file [url]http://www.segerdahl.info/25753/php.ini[/url]
    My httpd.conf file [url]http://www.segerdahl.info/25753/httpd.conf[/url]

    Server version: Apache/2.0.47
    Server built: Oct 20 2003 18:39:21

    PHP 4.3.4RC4 configured as:

    './configure' '--with-apxs2=/usr/local/httpd/bin/apxs'
    '--enable-mbstring' '--with-pear' '--with-mysql'
    '--enable-magic-quotes' '--with-ftp' '--sysconfdir=/etc/php'
    '--with-config-file-path=/etc/php' '--prefix=/usr/local/php/'
    '--enable-mbstring' '--with-curl' '--enable-ftp'

    APACHE configured as:
    ../configure --sysconfdir=/etc/httpd/conf --enable-ssl
    --prefix=/usr/local/httpd --enable-modules=dso,most

    Contact me on efnet if you need more information... // bad2da

    ------------------------------------------------------------------------

    [2003-10-04 18:58:16] [email]sniperphp.net[/email]

    We do not know what causes this bug or how it can be reliably
    reproduced. If you know exactly HOW this can be reproduced, add the
    information here. Any other comments will be deleted.


    ------------------------------------------------------------------------

    [2003-10-04 00:48:12] [email]sniperphp.net[/email]

    Description:
    ------------
    If (for example) one virtualhost configuration has
    set "php_admin_flag register_globals off", in some situations the
    setting persists between requests.
    -> php.ini settings are NOT reset between requests.

    1. php.ini has register_globals = On
    2. Request is made into [url]www.foobar.com[/url]
    (which has "php_admin_flag register_globals off")
    3. Next request (same apache child) is made into [url]www.barfoo.com[/url] (which
    does not have the setting)

    This applies to ALL php.ini directives.

    Some related reports:

    bug #6374 (include_path in .htaccess across multiple vhosts)
    bug #7174 (Round-robin -like values for include_path)
    bug #19292 (Random error: open_basedir restriction..)
    bug #21564 (corrupted paths coming to open_basedir)
    bug #23462 ("php_admin_value open_basedir" in httpd.conf)
    bug #23580 (Random values for include_path)
    bug #24282 (Strange Open Base Dir Restriction Errors)
    bug #24974 (random open_basedir errors)
    bug #25172 ($HTTP_HOST sometimes empty)

    For all who think they're experiencing this problem:
    DO NOT add any comments here unless you have some extra information to
    give which is not already given in above mentioned reports.
    Any comment which has no extra value will be deleted.




    ------------------------------------------------------------------------


    --
    Edit this bug report at [url]http://bugs.php.net/?id=25753&edit=1[/url]
    simon at implix dot com Guest

  10. #10

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: blitzer at cutery dot fi
    Reported By: net
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    A workaround I did seems to work until this is fixed: make php.ini
    automatically prepend a .php file that will reload the variables from
    the .ini file.


    Previous Comments:
    ------------------------------------------------------------------------

    [2003-11-08 12:38:07] simon at implix dot com

    We have a similar problem.

    We've got overlapping virtualhosts (as they
    are required for one of our application)
    and sometimes PHP returns register_globals = Off,
    even though = On is set in php.ini.

    We are using php 4.3.4 + apache 2.0.48.

    The problem doesn't exist when we use
    php 4.3.1.

    ------------------------------------------------------------------------

    [2003-10-30 09:35:44] fs at nessus dot at

    no thats false.
    this bug occours on apache 1.3.x too (tested it with 1.3.27).
    i think thats very essential...

    greetings,

    Florian Schicker
    www.nessus.at

    ------------------------------------------------------------------------

    [2003-10-28 04:13:33] mattias at segerdahl dot info

    This bug only appears when and if you have overlapping virtualhosts in
    apache2. Using fqdn's that have IN A or CNAME to an ipaddress on the
    server seems to fix it.

    This is only an observation that seems to have gotten rid of the
    problem for me.

    // bad2da

    ------------------------------------------------------------------------

    [2003-10-22 04:01:39] mattias at segerdahl dot info

    Sniper,

    I accidently ran into this bug a few moments ago. I talked to Derick
    about it in the channel and we agreed I would do some testing. There
    are some particular strange behaviour.

    I will try to explain as well as include the files needed to reproduce
    this error. But first let me point out one thing that I find really
    weird.

    This only occurs when the apache server has not been accessed for a
    while, if you reload the page directly after you've encountered this
    error message, it will work perfectly.

    The error message is:

    Warning: Unknown(): open_basedir restriction in effect.
    File(/var/www/users.bitcom.se/index.php) is not within the allowed
    path(s): (/var/www/www.sol.se) in Unknown on line 0
    Warning: Unknown(/var/www/users.bitcom.se/index.php): failed to open
    stream: Operation not permitted in Unknown on line 0
    Warning: (null)(): Failed opening '/var/www/users.bitcom.se/index.php'
    for inclusion (include_path='.:/usr/local/php//lib/php') in Unknown on
    line 0

    My php.ini file http://www.segerdahl.info/25753/php.ini
    My httpd.conf file http://www.segerdahl.info/25753/httpd.conf

    Server version: Apache/2.0.47
    Server built: Oct 20 2003 18:39:21

    PHP 4.3.4RC4 configured as:

    './configure' '--with-apxs2=/usr/local/httpd/bin/apxs'
    '--enable-mbstring' '--with-pear' '--with-mysql'
    '--enable-magic-quotes' '--with-ftp' '--sysconfdir=/etc/php'
    '--with-config-file-path=/etc/php' '--prefix=/usr/local/php/'
    '--enable-mbstring' '--with-curl' '--enable-ftp'

    APACHE configured as:
    ../configure --sysconfdir=/etc/httpd/conf --enable-ssl
    --prefix=/usr/local/httpd --enable-modules=dso,most

    Contact me on efnet if you need more information... // bad2da

    ------------------------------------------------------------------------

    [2003-10-04 18:58:16] net

    We do not know what causes this bug or how it can be reliably
    reproduced. If you know exactly HOW this can be reproduced, add the
    information here. Any other comments will be deleted.


    ------------------------------------------------------------------------

    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/25753

    --
    Edit this bug report at http://bugs.php.net/?id=25753&edit=1
    blitzer Guest

  11. #11

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: joris at ideeel dot nl
    Reported By: net
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    We experience this problem, but different PHP programs are differently
    susceptible to it
    problem: extra slashes before quotation marks (\" instead of ")
    vulnerable: PHPsysinfo & PHPnuke
    not vulnerable: Squirrelmail, phpBB, phpMyAdmin
    Tested on RH73 standard setup.

    joris


    Previous Comments:
    ------------------------------------------------------------------------

    [2003-11-28 10:07:31] blitzer at cutery dot fi

    A workaround I did seems to work until this is fixed: make php.ini
    automatically prepend a .php file that will reload the variables from
    the .ini file.

    ------------------------------------------------------------------------

    [2003-11-08 12:38:07] simon at implix dot com

    We have a similar problem.

    We've got overlapping virtualhosts (as they
    are required for one of our application)
    and sometimes PHP returns register_globals = Off,
    even though = On is set in php.ini.

    We are using php 4.3.4 + apache 2.0.48.

    The problem doesn't exist when we use
    php 4.3.1.

    ------------------------------------------------------------------------

    [2003-10-30 09:35:44] fs at nessus dot at

    no thats false.
    this bug occours on apache 1.3.x too (tested it with 1.3.27).
    i think thats very essential...

    greetings,

    Florian Schicker
    www.nessus.at

    ------------------------------------------------------------------------

    [2003-10-28 04:13:33] mattias at segerdahl dot info

    This bug only appears when and if you have overlapping virtualhosts in
    apache2. Using fqdn's that have IN A or CNAME to an ipaddress on the
    server seems to fix it.

    This is only an observation that seems to have gotten rid of the
    problem for me.

    // bad2da

    ------------------------------------------------------------------------

    [2003-10-22 04:01:39] mattias at segerdahl dot info

    Sniper,

    I accidently ran into this bug a few moments ago. I talked to Derick
    about it in the channel and we agreed I would do some testing. There
    are some particular strange behaviour.

    I will try to explain as well as include the files needed to reproduce
    this error. But first let me point out one thing that I find really
    weird.

    This only occurs when the apache server has not been accessed for a
    while, if you reload the page directly after you've encountered this
    error message, it will work perfectly.

    The error message is:

    Warning: Unknown(): open_basedir restriction in effect.
    File(/var/www/users.bitcom.se/index.php) is not within the allowed
    path(s): (/var/www/www.sol.se) in Unknown on line 0
    Warning: Unknown(/var/www/users.bitcom.se/index.php): failed to open
    stream: Operation not permitted in Unknown on line 0
    Warning: (null)(): Failed opening '/var/www/users.bitcom.se/index.php'
    for inclusion (include_path='.:/usr/local/php//lib/php') in Unknown on
    line 0

    My php.ini file http://www.segerdahl.info/25753/php.ini
    My httpd.conf file http://www.segerdahl.info/25753/httpd.conf

    Server version: Apache/2.0.47
    Server built: Oct 20 2003 18:39:21

    PHP 4.3.4RC4 configured as:

    './configure' '--with-apxs2=/usr/local/httpd/bin/apxs'
    '--enable-mbstring' '--with-pear' '--with-mysql'
    '--enable-magic-quotes' '--with-ftp' '--sysconfdir=/etc/php'
    '--with-config-file-path=/etc/php' '--prefix=/usr/local/php/'
    '--enable-mbstring' '--with-curl' '--enable-ftp'

    APACHE configured as:
    ../configure --sysconfdir=/etc/httpd/conf --enable-ssl
    --prefix=/usr/local/httpd --enable-modules=dso,most

    Contact me on efnet if you need more information... // bad2da

    ------------------------------------------------------------------------

    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/25753

    --
    Edit this bug report at http://bugs.php.net/?id=25753&edit=1
    joris Guest

  12. #12

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: dkh-php at nighttide dot net
    Reported By: net
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    This appears suspiciously similar to the bug I opened in 24248, only
    mention it here so that it can be included at the list of related
    reports.


    Previous Comments:
    ------------------------------------------------------------------------

    [2003-12-22 17:47:26] dkh-php at nighttide dot net

    This appears suspiciously similar to the bug I opened in 24248, only
    mention it here so that it can be included at the list of related
    reports.

    ------------------------------------------------------------------------

    [2003-12-04 15:49:20] net

    Try the following patch:
    http://bb.prohost.org/ap_bug.txt

    ------------------------------------------------------------------------

    [2003-10-30 09:35:44] fs at nessus dot at

    no thats false.
    this bug occours on apache 1.3.x too (tested it with 1.3.27).
    i think thats very essential...

    greetings,

    Florian Schicker
    www.nessus.at

    ------------------------------------------------------------------------

    [2003-10-28 04:13:33] mattias at segerdahl dot info

    This bug only appears when and if you have overlapping virtualhosts in
    apache2. Using fqdn's that have IN A or CNAME to an ipaddress on the
    server seems to fix it.

    This is only an observation that seems to have gotten rid of the
    problem for me.

    // bad2da

    ------------------------------------------------------------------------

    [2003-10-22 04:01:39] mattias at segerdahl dot info

    Sniper,

    I accidently ran into this bug a few moments ago. I talked to Derick
    about it in the channel and we agreed I would do some testing. There
    are some particular strange behaviour.

    I will try to explain as well as include the files needed to reproduce
    this error. But first let me point out one thing that I find really
    weird.

    This only occurs when the apache server has not been accessed for a
    while, if you reload the page directly after you've encountered this
    error message, it will work perfectly.

    The error message is:

    Warning: Unknown(): open_basedir restriction in effect.
    File(/var/www/users.bitcom.se/index.php) is not within the allowed
    path(s): (/var/www/www.sol.se) in Unknown on line 0
    Warning: Unknown(/var/www/users.bitcom.se/index.php): failed to open
    stream: Operation not permitted in Unknown on line 0
    Warning: (null)(): Failed opening '/var/www/users.bitcom.se/index.php'
    for inclusion (include_path='.:/usr/local/php//lib/php') in Unknown on
    line 0

    My php.ini file http://www.segerdahl.info/25753/php.ini
    My httpd.conf file http://www.segerdahl.info/25753/httpd.conf

    Server version: Apache/2.0.47
    Server built: Oct 20 2003 18:39:21

    PHP 4.3.4RC4 configured as:

    './configure' '--with-apxs2=/usr/local/httpd/bin/apxs'
    '--enable-mbstring' '--with-pear' '--with-mysql'
    '--enable-magic-quotes' '--with-ftp' '--sysconfdir=/etc/php'
    '--with-config-file-path=/etc/php' '--prefix=/usr/local/php/'
    '--enable-mbstring' '--with-curl' '--enable-ftp'

    APACHE configured as:
    ../configure --sysconfdir=/etc/httpd/conf --enable-ssl
    --prefix=/usr/local/httpd --enable-modules=dso,most

    Contact me on efnet if you need more information... // bad2da

    ------------------------------------------------------------------------

    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/25753

    --
    Edit this bug report at http://bugs.php.net/?id=25753&edit=1
    dkh-php Guest

  13. #13

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: rover at tob dot ru
    Reported By: net
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    It seems we have found a bug in mod_php4.c. We can 100% reproduce this
    error. How to reproduce (our case):
    in httpd.conf we have:

    # to enable only one instance of apache process
    StartServers 1
    MaxClients 1
    #
    <Directory /var/www/info/>
    php_value engine off
    </Directory>

    in php.ini:
    Engine = On,
    we enable php-scripts at all site, but disable in /info.

    Let's begin:
    #/usr/sbin/apache.dbg -f /etc/apache/httpd.conf
    #gbd /usr/sbin/apache.gdb pid_of_child (attach to child, what serve
    requests)
    (gdb)p php_apache_info.engine
    =1 ! php-engine ENABLED
    (gdb)watch php_apache_info.engine ! VERY IMPORTANT
    (gdb)break send_php ! bug in this func.
    (gdb)c

    1) Request a usual file from http://our.site/info/index.html:
    Because we define 'php_value off' for this directory - at line 829 in
    function php_xbithack_handler(remember - we process text/html) we call
    zend_hash_apply((HashTable *) per_dir_conf, (apply_func_t)
    php_apache_alter_ini_entries TSRMLS_CC);
    and change our 'engine' value to 0.
    backtrace for this call (don't look at line number - they shifted
    because i insert debug lines in source files):
    Hardware watchpoint 1: php_apache_info.engine
    Old value = 1
    New value = 0
    #0 OnUpdateInt (entry=0x80dc778, new_value=0x80d3cc4 "off",
    new_value_length=3, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=4) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    #1 0x4051110a in zend_alter_ini_entry (name=0x80de170 "engine",
    name_length=7, new_value=0x80de180 "off",
    new_value_length=3, modify_type=2, stage=4) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:212
    #2 0x40519fc6 in php_apache_alter_ini_entries
    (per_dir_entry=0x812c598)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:511
    #3 0x4050b8f9 in zend_hash_apply (ht=0x809fc98, apply_func=0x40519f40
    <php_apache_alter_ini_entries>)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:698
    #4 0x4051ad1b in php_xbithack_handler (r=0x81367ec)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:850
    #5 0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
    #6 0x08067e28 in process_request_internal (r=0x81367ec) at
    http_request.c:1332
    #7 0x08067fd4 in ap_process_request (r=0x81367ec) at
    http_request.c:1348
    #8 0x08060644 in child_main (child_num_arg=0) at http_main.c:4719
    #9 0x080607f7 in make_child (s=0x0, slot=0, now=0) at
    http_main.c:4898
    #10 0x08060920 in startup_children (number_to_start=1) at
    http_main.c:4925
    #11 0x0806149a in standalone_main (argc=1, argv=0xbffffdf4) at
    http_main.c:5244
    #12 0x08061a08 in main (argc=1, argv=0xbffffdf4) at http_main.c:5601

    Result of 1): we process http://our.site/info/index.html succefull and
    set global var 'engine'=0!

    Now we try to access http://our.site/index.php
    2) breakpoint 2 executed:
    Breakpoint 2, send_php (r=0x81367ec, display_source_mode=0,
    filename=0x0)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:544
    544 fh.free_filename = 0;
    #0 send_php (r=0x81367ec, display_source_mode=0, filename=0x0)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:544
    #1 0x4051a6eb in send_pd_php (r=0x81367ec) at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:655
    #2 0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
    #3 0x08067e28 in process_request_internal (r=0x81367ec) at
    http_request.c:1332
    #4 0x08067fd4 in ap_process_request (r=0x81367ec) at
    http_request.c:1348
    #5 0x08060644 in child_main (child_num_arg=135489516) at
    http_main.c:4719
    #6 0x080607f7 in make_child (s=0x81367ec, slot=0, now=135489516) at
    http_main.c:4898
    #7 0x08060920 in startup_children (number_to_start=1) at
    http_main.c:4925
    #8 0x0806149a in standalone_main (argc=1, argv=0xbffffdf4) at
    http_main.c:5244
    #9 0x08061a08 in main (argc=1, argv=0xbffffdf4) at http_main.c:5601

    But look at 'engine' - IT HAVE OLD VALUE = 0! What happend next:

    In mod_php4.c at line 570(original file from 4.3.3,4.3.4,4.3.5RC1) we
    have:
    if (!AP(engine)) {
    r->content_type = php_apache_get_default_mimetype(r
    TSRMLS_CC);
    r->allowed |= (1 << METHODS) - 1;
    zend_try {
    zend_ini_deactivate(TSRMLS_C);
    } zend_end_try();
    return DECLINED;
    }

    and instead serve index.php as x-application-php we only return
    DECLINE. Continue:

    3)(gdb)c
    Hardware watchpoint 1: php_apache_info.engine
    Old value = 0
    New value = 1
    OnUpdateInt (entry=0x80dc778, new_value=0x80b53e0 "1",
    new_value_length=1, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    453
    1: php_apache_info = {engine = 1, last_modified = 0, xbithack = 0,
    terminate_child = 0, in_request = 0 '\0'}
    (gdb) bt
    #0 OnUpdateInt (entry=0x80dc778, new_value=0x80b53e0 "1",
    new_value_length=1, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    #1 0x40510bcf in zend_restore_ini_entry_cb (ini_entry=0x80dc778,
    stage=8)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:51
    #2 0x4050b990 in zend_hash_apply_with_argument (ht=0x80b4f48,
    apply_func=0x40510b40 <zend_restore_ini_entry_cb>,
    argument=0x8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:717
    #3 0x40510cdb in zend_ini_deactivate () at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:89
    #4 0x40510b40 in zend_remove_ini_entries (ini_entry=0x90,
    module_number=0x0)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:44

    This only happend at line 574 where we RESET all variables to default
    value.

    To solve this bug we must RESET all ini_entries to default values in
    send_php function. Maybe authors suggest better method to restore
    default values instead using zend_ini_deactivate(TSRMLS_C);


    Previous Comments:
    ------------------------------------------------------------------------

    [2004-01-26 02:15:14] paul at vanbrouwershaven dot com

    Same problem with apache 2.0.48 and PHP 4.3.4

    We "solved" the problem by downgrading tot PHP 4.3.1

    ------------------------------------------------------------------------

    [2004-01-07 07:34:20] net

    Installing the patch resulted in a massive amount of errors from
    apache, all looking like:
    [notice] child pid 10072 exit signal Segmentation fault (11)

    .... about 10 of these per. second

    Eventually resulting in the apache server crashing.
    Requesting revised patch :)

    ------------------------------------------------------------------------

    [2004-01-07 07:11:27] net

    Regarding Bug #26810
    We are currently testing the suggested patch on two of our "troubled"
    servers to see if it resolves our problem.
    However the only way to get results from our tests is if our customers
    do not report more errors, so I'll report back in a week or so :)

    We are using Apache 1.3.28 and Apache 1.3.29 on the two servers, see
    more in Bug #26810

    ------------------------------------------------------------------------

    [2003-12-22 17:47:26] dkh-php at nighttide dot net

    This appears suspiciously similar to the bug I opened in 24248, only
    mention it here so that it can be included at the list of related
    reports.

    ------------------------------------------------------------------------

    [2003-12-04 15:49:20] net

    Try the following patch:
    http://bb.prohost.org/ap_bug.txt

    ------------------------------------------------------------------------

    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/25753

    --
    Edit this bug report at http://bugs.php.net/?id=25753&edit=1
    rover Guest

  14. #14

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: rover at tob dot ru
    Reported By: net
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    You can try this patch: (applied to 4.3.3, 4.3.4 and 4.3.5RC1
    versions):

    #patch -p1 -d source_dir_of_php < patch.diff

    diff -udr php-4.3.3/sapi/apache/mod_php4.c
    php-4.3.3.patched/sapi/apache/mod_php4.c
    --- php-4.3.3/sapi/apache/mod_php4.c 2003-06-03 11:41:49.000000000
    +0600
    +++ php-4.3.3.patched/sapi/apache/mod_php4.c 2004-01-27
    23:59:26.000000000 +0500
    -559,6 +559,11
    return DECLINED;
    }

    + /* Restore default ini settings */
    + zend_try {
    + zend_ini_deactivate(TSRMLS_C);
    + } zend_end_try();
    +
    per_dir_conf = (HashTable *)
    get_module_config(r->per_dir_config, &php4_module);
    if (per_dir_conf) {
    zend_hash_apply((HashTable *) per_dir_conf,
    (apply_func_t) php_apache_alter_ini_entries TSRMLS_C


    Previous Comments:
    ------------------------------------------------------------------------

    [2004-01-27 13:36:14] rover at tob dot ru

    It seems we have found a bug in mod_php4.c. We can 100% reproduce this
    error. How to reproduce (our case):
    in httpd.conf we have:

    # to enable only one instance of apache process
    StartServers 1
    MaxClients 1
    #
    <Directory /var/www/info/>
    php_value engine off
    </Directory>

    in php.ini:
    Engine = On,
    we enable php-scripts at all site, but disable in /info.

    Let's begin:
    #/usr/sbin/apache.dbg -f /etc/apache/httpd.conf
    #gbd /usr/sbin/apache.gdb pid_of_child (attach to child, what serve
    requests)
    (gdb)p php_apache_info.engine
    =1 ! php-engine ENABLED
    (gdb)watch php_apache_info.engine ! VERY IMPORTANT
    (gdb)break send_php ! bug in this func.
    (gdb)c

    1) Request a usual file from http://our.site/info/index.html:
    Because we define 'php_value off' for this directory - at line 829 in
    function php_xbithack_handler(remember - we process text/html) we call
    zend_hash_apply((HashTable *) per_dir_conf, (apply_func_t)
    php_apache_alter_ini_entries TSRMLS_CC);
    and change our 'engine' value to 0.
    backtrace for this call (don't look at line number - they shifted
    because i insert debug lines in source files):
    Hardware watchpoint 1: php_apache_info.engine
    Old value = 1
    New value = 0
    #0 OnUpdateInt (entry=0x80dc778, new_value=0x80d3cc4 "off",
    new_value_length=3, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=4) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    #1 0x4051110a in zend_alter_ini_entry (name=0x80de170 "engine",
    name_length=7, new_value=0x80de180 "off",
    new_value_length=3, modify_type=2, stage=4) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:212
    #2 0x40519fc6 in php_apache_alter_ini_entries
    (per_dir_entry=0x812c598)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:511
    #3 0x4050b8f9 in zend_hash_apply (ht=0x809fc98, apply_func=0x40519f40
    <php_apache_alter_ini_entries>)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:698
    #4 0x4051ad1b in php_xbithack_handler (r=0x81367ec)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:850
    #5 0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
    #6 0x08067e28 in process_request_internal (r=0x81367ec) at
    http_request.c:1332
    #7 0x08067fd4 in ap_process_request (r=0x81367ec) at
    http_request.c:1348
    #8 0x08060644 in child_main (child_num_arg=0) at http_main.c:4719
    #9 0x080607f7 in make_child (s=0x0, slot=0, now=0) at
    http_main.c:4898
    #10 0x08060920 in startup_children (number_to_start=1) at
    http_main.c:4925
    #11 0x0806149a in standalone_main (argc=1, argv=0xbffffdf4) at
    http_main.c:5244
    #12 0x08061a08 in main (argc=1, argv=0xbffffdf4) at http_main.c:5601

    Result of 1): we process http://our.site/info/index.html succefull and
    set global var 'engine'=0!

    Now we try to access http://our.site/index.php
    2) breakpoint 2 executed:
    Breakpoint 2, send_php (r=0x81367ec, display_source_mode=0,
    filename=0x0)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:544
    544 fh.free_filename = 0;
    #0 send_php (r=0x81367ec, display_source_mode=0, filename=0x0)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:544
    #1 0x4051a6eb in send_pd_php (r=0x81367ec) at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:655
    #2 0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
    #3 0x08067e28 in process_request_internal (r=0x81367ec) at
    http_request.c:1332
    #4 0x08067fd4 in ap_process_request (r=0x81367ec) at
    http_request.c:1348
    #5 0x08060644 in child_main (child_num_arg=135489516) at
    http_main.c:4719
    #6 0x080607f7 in make_child (s=0x81367ec, slot=0, now=135489516) at
    http_main.c:4898
    #7 0x08060920 in startup_children (number_to_start=1) at
    http_main.c:4925
    #8 0x0806149a in standalone_main (argc=1, argv=0xbffffdf4) at
    http_main.c:5244
    #9 0x08061a08 in main (argc=1, argv=0xbffffdf4) at http_main.c:5601

    But look at 'engine' - IT HAVE OLD VALUE = 0! What happend next:

    In mod_php4.c at line 570(original file from 4.3.3,4.3.4,4.3.5RC1) we
    have:
    if (!AP(engine)) {
    r->content_type = php_apache_get_default_mimetype(r
    TSRMLS_CC);
    r->allowed |= (1 << METHODS) - 1;
    zend_try {
    zend_ini_deactivate(TSRMLS_C);
    } zend_end_try();
    return DECLINED;
    }

    and instead serve index.php as x-application-php we only return
    DECLINE. Continue:

    3)(gdb)c
    Hardware watchpoint 1: php_apache_info.engine
    Old value = 0
    New value = 1
    OnUpdateInt (entry=0x80dc778, new_value=0x80b53e0 "1",
    new_value_length=1, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    453
    1: php_apache_info = {engine = 1, last_modified = 0, xbithack = 0,
    terminate_child = 0, in_request = 0 '\0'}
    (gdb) bt
    #0 OnUpdateInt (entry=0x80dc778, new_value=0x80b53e0 "1",
    new_value_length=1, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    #1 0x40510bcf in zend_restore_ini_entry_cb (ini_entry=0x80dc778,
    stage=8)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:51
    #2 0x4050b990 in zend_hash_apply_with_argument (ht=0x80b4f48,
    apply_func=0x40510b40 <zend_restore_ini_entry_cb>,
    argument=0x8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:717
    #3 0x40510cdb in zend_ini_deactivate () at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:89
    #4 0x40510b40 in zend_remove_ini_entries (ini_entry=0x90,
    module_number=0x0)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:44

    This only happend at line 574 where we RESET all variables to default
    value.

    To solve this bug we must RESET all ini_entries to default values in
    send_php function. Maybe authors suggest better method to restore
    default values instead using zend_ini_deactivate(TSRMLS_C);

    ------------------------------------------------------------------------

    [2004-01-26 02:15:14] paul at vanbrouwershaven dot com

    Same problem with apache 2.0.48 and PHP 4.3.4

    We "solved" the problem by downgrading tot PHP 4.3.1

    ------------------------------------------------------------------------

    [2004-01-07 07:34:20] net

    Installing the patch resulted in a massive amount of errors from
    apache, all looking like:
    [notice] child pid 10072 exit signal Segmentation fault (11)

    .... about 10 of these per. second

    Eventually resulting in the apache server crashing.
    Requesting revised patch :)

    ------------------------------------------------------------------------

    [2004-01-07 07:11:27] net

    Regarding Bug #26810
    We are currently testing the suggested patch on two of our "troubled"
    servers to see if it resolves our problem.
    However the only way to get results from our tests is if our customers
    do not report more errors, so I'll report back in a week or so :)

    We are using Apache 1.3.28 and Apache 1.3.29 on the two servers, see
    more in Bug #26810

    ------------------------------------------------------------------------

    [2003-12-22 17:47:26] dkh-php at nighttide dot net

    This appears suspiciously similar to the bug I opened in 24248, only
    mention it here so that it can be included at the list of related
    reports.

    ------------------------------------------------------------------------

    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/25753

    --
    Edit this bug report at http://bugs.php.net/?id=25753&edit=1
    rover Guest

  15. #15

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: rover at tob dot ru
    Reported By: net
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    Latest patch have a disadvantage: seems options like 'php_value engine
    on' now doesn't working in .htaccess directives. But now i don't have
    such annoying errors as early. Wait for developer solution. :)


    Previous Comments:
    ------------------------------------------------------------------------

    [2004-01-27 13:55:50] rover at tob dot ru

    You can try this patch: (applied to 4.3.3, 4.3.4 and 4.3.5RC1
    versions):

    #patch -p1 -d source_dir_of_php < patch.diff

    diff -udr php-4.3.3/sapi/apache/mod_php4.c
    php-4.3.3.patched/sapi/apache/mod_php4.c
    --- php-4.3.3/sapi/apache/mod_php4.c 2003-06-03 11:41:49.000000000
    +0600
    +++ php-4.3.3.patched/sapi/apache/mod_php4.c 2004-01-27
    23:59:26.000000000 +0500
    -559,6 +559,11
    return DECLINED;
    }

    + /* Restore default ini settings */
    + zend_try {
    + zend_ini_deactivate(TSRMLS_C);
    + } zend_end_try();
    +
    per_dir_conf = (HashTable *)
    get_module_config(r->per_dir_config, &php4_module);
    if (per_dir_conf) {
    zend_hash_apply((HashTable *) per_dir_conf,
    (apply_func_t) php_apache_alter_ini_entries TSRMLS_C

    ------------------------------------------------------------------------

    [2004-01-27 13:36:14] rover at tob dot ru

    It seems we have found a bug in mod_php4.c. We can 100% reproduce this
    error. How to reproduce (our case):
    in httpd.conf we have:

    # to enable only one instance of apache process
    StartServers 1
    MaxClients 1
    #
    <Directory /var/www/info/>
    php_value engine off
    </Directory>

    in php.ini:
    Engine = On,
    we enable php-scripts at all site, but disable in /info.

    Let's begin:
    #/usr/sbin/apache.dbg -f /etc/apache/httpd.conf
    #gbd /usr/sbin/apache.gdb pid_of_child (attach to child, what serve
    requests)
    (gdb)p php_apache_info.engine
    =1 ! php-engine ENABLED
    (gdb)watch php_apache_info.engine ! VERY IMPORTANT
    (gdb)break send_php ! bug in this func.
    (gdb)c

    1) Request a usual file from http://our.site/info/index.html:
    Because we define 'php_value off' for this directory - at line 829 in
    function php_xbithack_handler(remember - we process text/html) we call
    zend_hash_apply((HashTable *) per_dir_conf, (apply_func_t)
    php_apache_alter_ini_entries TSRMLS_CC);
    and change our 'engine' value to 0.
    backtrace for this call (don't look at line number - they shifted
    because i insert debug lines in source files):
    Hardware watchpoint 1: php_apache_info.engine
    Old value = 1
    New value = 0
    #0 OnUpdateInt (entry=0x80dc778, new_value=0x80d3cc4 "off",
    new_value_length=3, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=4) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    #1 0x4051110a in zend_alter_ini_entry (name=0x80de170 "engine",
    name_length=7, new_value=0x80de180 "off",
    new_value_length=3, modify_type=2, stage=4) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:212
    #2 0x40519fc6 in php_apache_alter_ini_entries
    (per_dir_entry=0x812c598)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:511
    #3 0x4050b8f9 in zend_hash_apply (ht=0x809fc98, apply_func=0x40519f40
    <php_apache_alter_ini_entries>)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:698
    #4 0x4051ad1b in php_xbithack_handler (r=0x81367ec)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:850
    #5 0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
    #6 0x08067e28 in process_request_internal (r=0x81367ec) at
    http_request.c:1332
    #7 0x08067fd4 in ap_process_request (r=0x81367ec) at
    http_request.c:1348
    #8 0x08060644 in child_main (child_num_arg=0) at http_main.c:4719
    #9 0x080607f7 in make_child (s=0x0, slot=0, now=0) at
    http_main.c:4898
    #10 0x08060920 in startup_children (number_to_start=1) at
    http_main.c:4925
    #11 0x0806149a in standalone_main (argc=1, argv=0xbffffdf4) at
    http_main.c:5244
    #12 0x08061a08 in main (argc=1, argv=0xbffffdf4) at http_main.c:5601

    Result of 1): we process http://our.site/info/index.html succefull and
    set global var 'engine'=0!

    Now we try to access http://our.site/index.php
    2) breakpoint 2 executed:
    Breakpoint 2, send_php (r=0x81367ec, display_source_mode=0,
    filename=0x0)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:544
    544 fh.free_filename = 0;
    #0 send_php (r=0x81367ec, display_source_mode=0, filename=0x0)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:544
    #1 0x4051a6eb in send_pd_php (r=0x81367ec) at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:655
    #2 0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
    #3 0x08067e28 in process_request_internal (r=0x81367ec) at
    http_request.c:1332
    #4 0x08067fd4 in ap_process_request (r=0x81367ec) at
    http_request.c:1348
    #5 0x08060644 in child_main (child_num_arg=135489516) at
    http_main.c:4719
    #6 0x080607f7 in make_child (s=0x81367ec, slot=0, now=135489516) at
    http_main.c:4898
    #7 0x08060920 in startup_children (number_to_start=1) at
    http_main.c:4925
    #8 0x0806149a in standalone_main (argc=1, argv=0xbffffdf4) at
    http_main.c:5244
    #9 0x08061a08 in main (argc=1, argv=0xbffffdf4) at http_main.c:5601

    But look at 'engine' - IT HAVE OLD VALUE = 0! What happend next:

    In mod_php4.c at line 570(original file from 4.3.3,4.3.4,4.3.5RC1) we
    have:
    if (!AP(engine)) {
    r->content_type = php_apache_get_default_mimetype(r
    TSRMLS_CC);
    r->allowed |= (1 << METHODS) - 1;
    zend_try {
    zend_ini_deactivate(TSRMLS_C);
    } zend_end_try();
    return DECLINED;
    }

    and instead serve index.php as x-application-php we only return
    DECLINE. Continue:

    3)(gdb)c
    Hardware watchpoint 1: php_apache_info.engine
    Old value = 0
    New value = 1
    OnUpdateInt (entry=0x80dc778, new_value=0x80b53e0 "1",
    new_value_length=1, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    453
    1: php_apache_info = {engine = 1, last_modified = 0, xbithack = 0,
    terminate_child = 0, in_request = 0 '\0'}
    (gdb) bt
    #0 OnUpdateInt (entry=0x80dc778, new_value=0x80b53e0 "1",
    new_value_length=1, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    #1 0x40510bcf in zend_restore_ini_entry_cb (ini_entry=0x80dc778,
    stage=8)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:51
    #2 0x4050b990 in zend_hash_apply_with_argument (ht=0x80b4f48,
    apply_func=0x40510b40 <zend_restore_ini_entry_cb>,
    argument=0x8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:717
    #3 0x40510cdb in zend_ini_deactivate () at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:89
    #4 0x40510b40 in zend_remove_ini_entries (ini_entry=0x90,
    module_number=0x0)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:44

    This only happend at line 574 where we RESET all variables to default
    value.

    To solve this bug we must RESET all ini_entries to default values in
    send_php function. Maybe authors suggest better method to restore
    default values instead using zend_ini_deactivate(TSRMLS_C);

    ------------------------------------------------------------------------

    [2004-01-26 02:15:14] paul at vanbrouwershaven dot com

    Same problem with apache 2.0.48 and PHP 4.3.4

    We "solved" the problem by downgrading tot PHP 4.3.1

    ------------------------------------------------------------------------

    [2004-01-07 07:34:20] net

    Installing the patch resulted in a massive amount of errors from
    apache, all looking like:
    [notice] child pid 10072 exit signal Segmentation fault (11)

    .... about 10 of these per. second

    Eventually resulting in the apache server crashing.
    Requesting revised patch :)

    ------------------------------------------------------------------------

    [2004-01-07 07:11:27] net

    Regarding Bug #26810
    We are currently testing the suggested patch on two of our "troubled"
    servers to see if it resolves our problem.
    However the only way to get results from our tests is if our customers
    do not report more errors, so I'll report back in a week or so :)

    We are using Apache 1.3.28 and Apache 1.3.29 on the two servers, see
    more in Bug #26810

    ------------------------------------------------------------------------

    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/25753

    --
    Edit this bug report at http://bugs.php.net/?id=25753&edit=1
    rover Guest

  16. #16

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: rover at tob dot ru
    Reported By: net
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    2 hour later....

    We yze this bug more carefully.

    THIS BUG VERY CRITICAL AND HAVE HUGE SECURITY IMPACT!

    message with explanation are sent to net,
    debian.org


    Previous Comments:
    ------------------------------------------------------------------------

    [2004-01-27 14:20:05] rover at tob dot ru

    Latest patch have a disadvantage: seems options like 'php_value engine
    on' now doesn't working in .htaccess directives. But now i don't have
    such annoying errors as early. Wait for developer solution. :)

    ------------------------------------------------------------------------

    [2004-01-27 13:55:50] rover at tob dot ru

    You can try this patch: (applied to 4.3.3, 4.3.4 and 4.3.5RC1
    versions):

    #patch -p1 -d source_dir_of_php < patch.diff

    diff -udr php-4.3.3/sapi/apache/mod_php4.c
    php-4.3.3.patched/sapi/apache/mod_php4.c
    --- php-4.3.3/sapi/apache/mod_php4.c 2003-06-03 11:41:49.000000000
    +0600
    +++ php-4.3.3.patched/sapi/apache/mod_php4.c 2004-01-27
    23:59:26.000000000 +0500
    -559,6 +559,11
    return DECLINED;
    }

    + /* Restore default ini settings */
    + zend_try {
    + zend_ini_deactivate(TSRMLS_C);
    + } zend_end_try();
    +
    per_dir_conf = (HashTable *)
    get_module_config(r->per_dir_config, &php4_module);
    if (per_dir_conf) {
    zend_hash_apply((HashTable *) per_dir_conf,
    (apply_func_t) php_apache_alter_ini_entries TSRMLS_C

    ------------------------------------------------------------------------

    [2004-01-27 13:36:14] rover at tob dot ru

    It seems we have found a bug in mod_php4.c. We can 100% reproduce this
    error. How to reproduce (our case):
    in httpd.conf we have:

    # to enable only one instance of apache process
    StartServers 1
    MaxClients 1
    #
    <Directory /var/www/info/>
    php_value engine off
    </Directory>

    in php.ini:
    Engine = On,
    we enable php-scripts at all site, but disable in /info.

    Let's begin:
    #/usr/sbin/apache.dbg -f /etc/apache/httpd.conf
    #gbd /usr/sbin/apache.gdb pid_of_child (attach to child, what serve
    requests)
    (gdb)p php_apache_info.engine
    =1 ! php-engine ENABLED
    (gdb)watch php_apache_info.engine ! VERY IMPORTANT
    (gdb)break send_php ! bug in this func.
    (gdb)c

    1) Request a usual file from http://our.site/info/index.html:
    Because we define 'php_value off' for this directory - at line 829 in
    function php_xbithack_handler(remember - we process text/html) we call
    zend_hash_apply((HashTable *) per_dir_conf, (apply_func_t)
    php_apache_alter_ini_entries TSRMLS_CC);
    and change our 'engine' value to 0.
    backtrace for this call (don't look at line number - they shifted
    because i insert debug lines in source files):
    Hardware watchpoint 1: php_apache_info.engine
    Old value = 1
    New value = 0
    #0 OnUpdateInt (entry=0x80dc778, new_value=0x80d3cc4 "off",
    new_value_length=3, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=4) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    #1 0x4051110a in zend_alter_ini_entry (name=0x80de170 "engine",
    name_length=7, new_value=0x80de180 "off",
    new_value_length=3, modify_type=2, stage=4) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:212
    #2 0x40519fc6 in php_apache_alter_ini_entries
    (per_dir_entry=0x812c598)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:511
    #3 0x4050b8f9 in zend_hash_apply (ht=0x809fc98, apply_func=0x40519f40
    <php_apache_alter_ini_entries>)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:698
    #4 0x4051ad1b in php_xbithack_handler (r=0x81367ec)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:850
    #5 0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
    #6 0x08067e28 in process_request_internal (r=0x81367ec) at
    http_request.c:1332
    #7 0x08067fd4 in ap_process_request (r=0x81367ec) at
    http_request.c:1348
    #8 0x08060644 in child_main (child_num_arg=0) at http_main.c:4719
    #9 0x080607f7 in make_child (s=0x0, slot=0, now=0) at
    http_main.c:4898
    #10 0x08060920 in startup_children (number_to_start=1) at
    http_main.c:4925
    #11 0x0806149a in standalone_main (argc=1, argv=0xbffffdf4) at
    http_main.c:5244
    #12 0x08061a08 in main (argc=1, argv=0xbffffdf4) at http_main.c:5601

    Result of 1): we process http://our.site/info/index.html succefull and
    set global var 'engine'=0!

    Now we try to access http://our.site/index.php
    2) breakpoint 2 executed:
    Breakpoint 2, send_php (r=0x81367ec, display_source_mode=0,
    filename=0x0)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:544
    544 fh.free_filename = 0;
    #0 send_php (r=0x81367ec, display_source_mode=0, filename=0x0)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:544
    #1 0x4051a6eb in send_pd_php (r=0x81367ec) at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:655
    #2 0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
    #3 0x08067e28 in process_request_internal (r=0x81367ec) at
    http_request.c:1332
    #4 0x08067fd4 in ap_process_request (r=0x81367ec) at
    http_request.c:1348
    #5 0x08060644 in child_main (child_num_arg=135489516) at
    http_main.c:4719
    #6 0x080607f7 in make_child (s=0x81367ec, slot=0, now=135489516) at
    http_main.c:4898
    #7 0x08060920 in startup_children (number_to_start=1) at
    http_main.c:4925
    #8 0x0806149a in standalone_main (argc=1, argv=0xbffffdf4) at
    http_main.c:5244
    #9 0x08061a08 in main (argc=1, argv=0xbffffdf4) at http_main.c:5601

    But look at 'engine' - IT HAVE OLD VALUE = 0! What happend next:

    In mod_php4.c at line 570(original file from 4.3.3,4.3.4,4.3.5RC1) we
    have:
    if (!AP(engine)) {
    r->content_type = php_apache_get_default_mimetype(r
    TSRMLS_CC);
    r->allowed |= (1 << METHODS) - 1;
    zend_try {
    zend_ini_deactivate(TSRMLS_C);
    } zend_end_try();
    return DECLINED;
    }

    and instead serve index.php as x-application-php we only return
    DECLINE. Continue:

    3)(gdb)c
    Hardware watchpoint 1: php_apache_info.engine
    Old value = 0
    New value = 1
    OnUpdateInt (entry=0x80dc778, new_value=0x80b53e0 "1",
    new_value_length=1, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    453
    1: php_apache_info = {engine = 1, last_modified = 0, xbithack = 0,
    terminate_child = 0, in_request = 0 '\0'}
    (gdb) bt
    #0 OnUpdateInt (entry=0x80dc778, new_value=0x80b53e0 "1",
    new_value_length=1, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    #1 0x40510bcf in zend_restore_ini_entry_cb (ini_entry=0x80dc778,
    stage=8)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:51
    #2 0x4050b990 in zend_hash_apply_with_argument (ht=0x80b4f48,
    apply_func=0x40510b40 <zend_restore_ini_entry_cb>,
    argument=0x8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:717
    #3 0x40510cdb in zend_ini_deactivate () at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:89
    #4 0x40510b40 in zend_remove_ini_entries (ini_entry=0x90,
    module_number=0x0)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:44

    This only happend at line 574 where we RESET all variables to default
    value.

    To solve this bug we must RESET all ini_entries to default values in
    send_php function. Maybe authors suggest better method to restore
    default values instead using zend_ini_deactivate(TSRMLS_C);

    ------------------------------------------------------------------------

    [2004-01-26 02:15:14] paul at vanbrouwershaven dot com

    Same problem with apache 2.0.48 and PHP 4.3.4

    We "solved" the problem by downgrading tot PHP 4.3.1

    ------------------------------------------------------------------------

    [2004-01-07 07:34:20] net

    Installing the patch resulted in a massive amount of errors from
    apache, all looking like:
    [notice] child pid 10072 exit signal Segmentation fault (11)

    .... about 10 of these per. second

    Eventually resulting in the apache server crashing.
    Requesting revised patch :)

    ------------------------------------------------------------------------

    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/25753

    --
    Edit this bug report at http://bugs.php.net/?id=25753&edit=1
    rover Guest

  17. #17

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: rover at tob dot ru
    Reported By: net
    Status: Critical
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    We examine source files more carefull and remake a patch:

    diff -udr php-4.3.3/sapi/apache/mod_php4.c
    php-4.3.3.patched/sapi/apache/mod_php4.c
    --- php-4.3.3/sapi/apache/mod_php4.c 2003-06-03 11:41:49.000000000
    +0600
    +++ php-4.3.3.patched/sapi/apache/mod_php4.c 2004-01-28
    10:48:27.000000000 +0500
    -830,6 +830,9
    }
    if(!AP(xbithack)) {
    r->allowed |= (1 << METHODS) - 1;
    + zend_try {
    + zend_ini_deactivate(TSRMLS_C);
    + } zend_end_try();
    return DECLINED;
    }
    return send_pd_php(r);


    Previous Comments:
    ------------------------------------------------------------------------

    [2004-01-27 16:08:12] rover at tob dot ru

    2 hour later....

    We yze this bug more carefully.

    THIS BUG VERY CRITICAL AND HAVE HUGE SECURITY IMPACT!

    message with explanation are sent to net,
    debian.org

    ------------------------------------------------------------------------

    [2004-01-27 14:20:05] rover at tob dot ru

    Latest patch have a disadvantage: seems options like 'php_value engine
    on' now doesn't working in .htaccess directives. But now i don't have
    such annoying errors as early. Wait for developer solution. :)

    ------------------------------------------------------------------------

    [2004-01-27 13:55:50] rover at tob dot ru

    You can try this patch: (applied to 4.3.3, 4.3.4 and 4.3.5RC1
    versions):

    #patch -p1 -d source_dir_of_php < patch.diff

    diff -udr php-4.3.3/sapi/apache/mod_php4.c
    php-4.3.3.patched/sapi/apache/mod_php4.c
    --- php-4.3.3/sapi/apache/mod_php4.c 2003-06-03 11:41:49.000000000
    +0600
    +++ php-4.3.3.patched/sapi/apache/mod_php4.c 2004-01-27
    23:59:26.000000000 +0500
    -559,6 +559,11
    return DECLINED;
    }

    + /* Restore default ini settings */
    + zend_try {
    + zend_ini_deactivate(TSRMLS_C);
    + } zend_end_try();
    +
    per_dir_conf = (HashTable *)
    get_module_config(r->per_dir_config, &php4_module);
    if (per_dir_conf) {
    zend_hash_apply((HashTable *) per_dir_conf,
    (apply_func_t) php_apache_alter_ini_entries TSRMLS_C

    ------------------------------------------------------------------------

    [2004-01-27 13:36:14] rover at tob dot ru

    It seems we have found a bug in mod_php4.c. We can 100% reproduce this
    error. How to reproduce (our case):
    in httpd.conf we have:

    # to enable only one instance of apache process
    StartServers 1
    MaxClients 1
    #
    <Directory /var/www/info/>
    php_value engine off
    </Directory>

    in php.ini:
    Engine = On,
    we enable php-scripts at all site, but disable in /info.

    Let's begin:
    #/usr/sbin/apache.dbg -f /etc/apache/httpd.conf
    #gbd /usr/sbin/apache.gdb pid_of_child (attach to child, what serve
    requests)
    (gdb)p php_apache_info.engine
    =1 ! php-engine ENABLED
    (gdb)watch php_apache_info.engine ! VERY IMPORTANT
    (gdb)break send_php ! bug in this func.
    (gdb)c

    1) Request a usual file from http://our.site/info/index.html:
    Because we define 'php_value off' for this directory - at line 829 in
    function php_xbithack_handler(remember - we process text/html) we call
    zend_hash_apply((HashTable *) per_dir_conf, (apply_func_t)
    php_apache_alter_ini_entries TSRMLS_CC);
    and change our 'engine' value to 0.
    backtrace for this call (don't look at line number - they shifted
    because i insert debug lines in source files):
    Hardware watchpoint 1: php_apache_info.engine
    Old value = 1
    New value = 0
    #0 OnUpdateInt (entry=0x80dc778, new_value=0x80d3cc4 "off",
    new_value_length=3, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=4) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    #1 0x4051110a in zend_alter_ini_entry (name=0x80de170 "engine",
    name_length=7, new_value=0x80de180 "off",
    new_value_length=3, modify_type=2, stage=4) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:212
    #2 0x40519fc6 in php_apache_alter_ini_entries
    (per_dir_entry=0x812c598)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:511
    #3 0x4050b8f9 in zend_hash_apply (ht=0x809fc98, apply_func=0x40519f40
    <php_apache_alter_ini_entries>)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:698
    #4 0x4051ad1b in php_xbithack_handler (r=0x81367ec)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:850
    #5 0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
    #6 0x08067e28 in process_request_internal (r=0x81367ec) at
    http_request.c:1332
    #7 0x08067fd4 in ap_process_request (r=0x81367ec) at
    http_request.c:1348
    #8 0x08060644 in child_main (child_num_arg=0) at http_main.c:4719
    #9 0x080607f7 in make_child (s=0x0, slot=0, now=0) at
    http_main.c:4898
    #10 0x08060920 in startup_children (number_to_start=1) at
    http_main.c:4925
    #11 0x0806149a in standalone_main (argc=1, argv=0xbffffdf4) at
    http_main.c:5244
    #12 0x08061a08 in main (argc=1, argv=0xbffffdf4) at http_main.c:5601

    Result of 1): we process http://our.site/info/index.html succefull and
    set global var 'engine'=0!

    Now we try to access http://our.site/index.php
    2) breakpoint 2 executed:
    Breakpoint 2, send_php (r=0x81367ec, display_source_mode=0,
    filename=0x0)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:544
    544 fh.free_filename = 0;
    #0 send_php (r=0x81367ec, display_source_mode=0, filename=0x0)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:544
    #1 0x4051a6eb in send_pd_php (r=0x81367ec) at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:655
    #2 0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
    #3 0x08067e28 in process_request_internal (r=0x81367ec) at
    http_request.c:1332
    #4 0x08067fd4 in ap_process_request (r=0x81367ec) at
    http_request.c:1348
    #5 0x08060644 in child_main (child_num_arg=135489516) at
    http_main.c:4719
    #6 0x080607f7 in make_child (s=0x81367ec, slot=0, now=135489516) at
    http_main.c:4898
    #7 0x08060920 in startup_children (number_to_start=1) at
    http_main.c:4925
    #8 0x0806149a in standalone_main (argc=1, argv=0xbffffdf4) at
    http_main.c:5244
    #9 0x08061a08 in main (argc=1, argv=0xbffffdf4) at http_main.c:5601

    But look at 'engine' - IT HAVE OLD VALUE = 0! What happend next:

    In mod_php4.c at line 570(original file from 4.3.3,4.3.4,4.3.5RC1) we
    have:
    if (!AP(engine)) {
    r->content_type = php_apache_get_default_mimetype(r
    TSRMLS_CC);
    r->allowed |= (1 << METHODS) - 1;
    zend_try {
    zend_ini_deactivate(TSRMLS_C);
    } zend_end_try();
    return DECLINED;
    }

    and instead serve index.php as x-application-php we only return
    DECLINE. Continue:

    3)(gdb)c
    Hardware watchpoint 1: php_apache_info.engine
    Old value = 0
    New value = 1
    OnUpdateInt (entry=0x80dc778, new_value=0x80b53e0 "1",
    new_value_length=1, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    453
    1: php_apache_info = {engine = 1, last_modified = 0, xbithack = 0,
    terminate_child = 0, in_request = 0 '\0'}
    (gdb) bt
    #0 OnUpdateInt (entry=0x80dc778, new_value=0x80b53e0 "1",
    new_value_length=1, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    #1 0x40510bcf in zend_restore_ini_entry_cb (ini_entry=0x80dc778,
    stage=8)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:51
    #2 0x4050b990 in zend_hash_apply_with_argument (ht=0x80b4f48,
    apply_func=0x40510b40 <zend_restore_ini_entry_cb>,
    argument=0x8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:717
    #3 0x40510cdb in zend_ini_deactivate () at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:89
    #4 0x40510b40 in zend_remove_ini_entries (ini_entry=0x90,
    module_number=0x0)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:44

    This only happend at line 574 where we RESET all variables to default
    value.

    To solve this bug we must RESET all ini_entries to default values in
    send_php function. Maybe authors suggest better method to restore
    default values instead using zend_ini_deactivate(TSRMLS_C);

    ------------------------------------------------------------------------

    [2004-01-26 02:15:14] paul at vanbrouwershaven dot com

    Same problem with apache 2.0.48 and PHP 4.3.4

    We "solved" the problem by downgrading tot PHP 4.3.1

    ------------------------------------------------------------------------

    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/25753

    --
    Edit this bug report at http://bugs.php.net/?id=25753&edit=1
    rover Guest

  18. #18

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: rover at tob dot ru
    Reported By: net
    Status: Closed
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    Anyway - in some case this can lead to security violation.
    Apache2 module are vulnerable to this bug?


    Previous Comments:
    ------------------------------------------------------------------------

    [2004-01-28 12:40:04] net

    This only happens on text/html files with the executable bit set. If
    the +x bit is set, we load the current ini settings and if php's
    xbithack option is not set we decline the request but forget to reset
    the ini settings potentially leaking them to the next request. This is
    now fixed in CVS and will be in the next release of both PHP4 and PHP5.

    ------------------------------------------------------------------------

    [2004-01-28 00:47:04] rover at tob dot ru

    We examine source files more carefull and remake a patch:

    diff -udr php-4.3.3/sapi/apache/mod_php4.c
    php-4.3.3.patched/sapi/apache/mod_php4.c
    --- php-4.3.3/sapi/apache/mod_php4.c 2003-06-03 11:41:49.000000000
    +0600
    +++ php-4.3.3.patched/sapi/apache/mod_php4.c 2004-01-28
    10:48:27.000000000 +0500
    -830,6 +830,9
    }
    if(!AP(xbithack)) {
    r->allowed |= (1 << METHODS) - 1;
    + zend_try {
    + zend_ini_deactivate(TSRMLS_C);
    + } zend_end_try();
    return DECLINED;
    }
    return send_pd_php(r);

    ------------------------------------------------------------------------

    [2004-01-27 16:08:12] rover at tob dot ru

    2 hour later....

    We yze this bug more carefully.

    THIS BUG VERY CRITICAL AND HAVE HUGE SECURITY IMPACT!

    message with explanation are sent to net,
    debian.org

    ------------------------------------------------------------------------

    [2004-01-27 14:20:05] rover at tob dot ru

    Latest patch have a disadvantage: seems options like 'php_value engine
    on' now doesn't working in .htaccess directives. But now i don't have
    such annoying errors as early. Wait for developer solution. :)

    ------------------------------------------------------------------------

    [2004-01-27 13:55:50] rover at tob dot ru

    You can try this patch: (applied to 4.3.3, 4.3.4 and 4.3.5RC1
    versions):

    #patch -p1 -d source_dir_of_php < patch.diff

    diff -udr php-4.3.3/sapi/apache/mod_php4.c
    php-4.3.3.patched/sapi/apache/mod_php4.c
    --- php-4.3.3/sapi/apache/mod_php4.c 2003-06-03 11:41:49.000000000
    +0600
    +++ php-4.3.3.patched/sapi/apache/mod_php4.c 2004-01-27
    23:59:26.000000000 +0500
    -559,6 +559,11
    return DECLINED;
    }

    + /* Restore default ini settings */
    + zend_try {
    + zend_ini_deactivate(TSRMLS_C);
    + } zend_end_try();
    +
    per_dir_conf = (HashTable *)
    get_module_config(r->per_dir_config, &php4_module);
    if (per_dir_conf) {
    zend_hash_apply((HashTable *) per_dir_conf,
    (apply_func_t) php_apache_alter_ini_entries TSRMLS_C

    ------------------------------------------------------------------------

    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/25753

    --
    Edit this bug report at http://bugs.php.net/?id=25753&edit=1
    rover Guest

  19. #19

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: david at bizeweb dot com
    Reported By: net
    Status: Closed
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    I a related problem to an apache list, and someone directed me to here.
    I thought timing was so perfect and that the problem was fixed.
    However, I think this bug still exists. Unless I need to install a
    specific CVS version. I have php4-STABLE-200402012230 installed on a
    RH9 with apache2.0.44 with a php config of
    CFLAGS="-I/usr/kerberos/include -DSECURITY_HOLE_PASS_AUTHORIZATION"
    ../configure --with-apxs2=/usr/local/apache/bin/apxs --with-gettext
    --with-imap=/dl/imap-2001a --with-kerberos --with-glibcc --with-xml
    --with-mysql.

    I've isolated my server and in my httpd.conf have set the following for
    easy testing.
    StartServers 1
    MinSpareServers 1
    MaxSpareServers 2

    <VirtualHost x.x.x.x:80>
    ServerName foo.com
    </VirtualHost>

    <VirtualHost x.x.x.x:80>
    php_admin_flag engine off
    ServerName foo2.com
    </VirtualHost>
    I can keep going to foo.com without any problems as soon as I goto
    foo2.com, then foo.com will attempt to dl the php files.
    I'm new to this field, but if I can help just ask.


    Previous Comments:
    ------------------------------------------------------------------------

    [2004-01-28 12:40:04] net

    This only happens on text/html files with the executable bit set. If
    the +x bit is set, we load the current ini settings and if php's
    xbithack option is not set we decline the request but forget to reset
    the ini settings potentially leaking them to the next request. This is
    now fixed in CVS and will be in the next release of both PHP4 and PHP5.

    ------------------------------------------------------------------------

    [2004-01-28 00:47:04] rover at tob dot ru

    We examine source files more carefull and remake a patch:

    diff -udr php-4.3.3/sapi/apache/mod_php4.c
    php-4.3.3.patched/sapi/apache/mod_php4.c
    --- php-4.3.3/sapi/apache/mod_php4.c 2003-06-03 11:41:49.000000000
    +0600
    +++ php-4.3.3.patched/sapi/apache/mod_php4.c 2004-01-28
    10:48:27.000000000 +0500
    -830,6 +830,9
    }
    if(!AP(xbithack)) {
    r->allowed |= (1 << METHODS) - 1;
    + zend_try {
    + zend_ini_deactivate(TSRMLS_C);
    + } zend_end_try();
    return DECLINED;
    }
    return send_pd_php(r);

    ------------------------------------------------------------------------

    [2004-01-27 13:36:14] rover at tob dot ru

    It seems we have found a bug in mod_php4.c. We can 100% reproduce this
    error. How to reproduce (our case):
    in httpd.conf we have:

    # to enable only one instance of apache process
    StartServers 1
    MaxClients 1
    #
    <Directory /var/www/info/>
    php_value engine off
    </Directory>

    in php.ini:
    Engine = On,
    we enable php-scripts at all site, but disable in /info.

    Let's begin:
    #/usr/sbin/apache.dbg -f /etc/apache/httpd.conf
    #gbd /usr/sbin/apache.gdb pid_of_child (attach to child, what serve
    requests)
    (gdb)p php_apache_info.engine
    =1 ! php-engine ENABLED
    (gdb)watch php_apache_info.engine ! VERY IMPORTANT
    (gdb)break send_php ! bug in this func.
    (gdb)c

    1) Request a usual file from http://our.site/info/index.html:
    Because we define 'php_value off' for this directory - at line 829 in
    function php_xbithack_handler(remember - we process text/html) we call
    zend_hash_apply((HashTable *) per_dir_conf, (apply_func_t)
    php_apache_alter_ini_entries TSRMLS_CC);
    and change our 'engine' value to 0.
    backtrace for this call (don't look at line number - they shifted
    because i insert debug lines in source files):
    Hardware watchpoint 1: php_apache_info.engine
    Old value = 1
    New value = 0
    #0 OnUpdateInt (entry=0x80dc778, new_value=0x80d3cc4 "off",
    new_value_length=3, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=4) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    #1 0x4051110a in zend_alter_ini_entry (name=0x80de170 "engine",
    name_length=7, new_value=0x80de180 "off",
    new_value_length=3, modify_type=2, stage=4) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:212
    #2 0x40519fc6 in php_apache_alter_ini_entries
    (per_dir_entry=0x812c598)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:511
    #3 0x4050b8f9 in zend_hash_apply (ht=0x809fc98, apply_func=0x40519f40
    <php_apache_alter_ini_entries>)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:698
    #4 0x4051ad1b in php_xbithack_handler (r=0x81367ec)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:850
    #5 0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
    #6 0x08067e28 in process_request_internal (r=0x81367ec) at
    http_request.c:1332
    #7 0x08067fd4 in ap_process_request (r=0x81367ec) at
    http_request.c:1348
    #8 0x08060644 in child_main (child_num_arg=0) at http_main.c:4719
    #9 0x080607f7 in make_child (s=0x0, slot=0, now=0) at
    http_main.c:4898
    #10 0x08060920 in startup_children (number_to_start=1) at
    http_main.c:4925
    #11 0x0806149a in standalone_main (argc=1, argv=0xbffffdf4) at
    http_main.c:5244
    #12 0x08061a08 in main (argc=1, argv=0xbffffdf4) at http_main.c:5601

    Result of 1): we process http://our.site/info/index.html succefull and
    set global var 'engine'=0!

    Now we try to access http://our.site/index.php
    2) breakpoint 2 executed:
    Breakpoint 2, send_php (r=0x81367ec, display_source_mode=0,
    filename=0x0)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:544
    544 fh.free_filename = 0;
    #0 send_php (r=0x81367ec, display_source_mode=0, filename=0x0)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:544
    #1 0x4051a6eb in send_pd_php (r=0x81367ec) at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:655
    #2 0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
    #3 0x08067e28 in process_request_internal (r=0x81367ec) at
    http_request.c:1332
    #4 0x08067fd4 in ap_process_request (r=0x81367ec) at
    http_request.c:1348
    #5 0x08060644 in child_main (child_num_arg=135489516) at
    http_main.c:4719
    #6 0x080607f7 in make_child (s=0x81367ec, slot=0, now=135489516) at
    http_main.c:4898
    #7 0x08060920 in startup_children (number_to_start=1) at
    http_main.c:4925
    #8 0x0806149a in standalone_main (argc=1, argv=0xbffffdf4) at
    http_main.c:5244
    #9 0x08061a08 in main (argc=1, argv=0xbffffdf4) at http_main.c:5601

    But look at 'engine' - IT HAVE OLD VALUE = 0! What happend next:

    In mod_php4.c at line 570(original file from 4.3.3,4.3.4,4.3.5RC1) we
    have:
    if (!AP(engine)) {
    r->content_type = php_apache_get_default_mimetype(r
    TSRMLS_CC);
    r->allowed |= (1 << METHODS) - 1;
    zend_try {
    zend_ini_deactivate(TSRMLS_C);
    } zend_end_try();
    return DECLINED;
    }

    and instead serve index.php as x-application-php we only return
    DECLINE. Continue:

    3)(gdb)c
    Hardware watchpoint 1: php_apache_info.engine
    Old value = 0
    New value = 1
    OnUpdateInt (entry=0x80dc778, new_value=0x80b53e0 "1",
    new_value_length=1, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    453
    1: php_apache_info = {engine = 1, last_modified = 0, xbithack = 0,
    terminate_child = 0, in_request = 0 '\0'}
    (gdb) bt
    #0 OnUpdateInt (entry=0x80dc778, new_value=0x80b53e0 "1",
    new_value_length=1, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    #1 0x40510bcf in zend_restore_ini_entry_cb (ini_entry=0x80dc778,
    stage=8)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:51
    #2 0x4050b990 in zend_hash_apply_with_argument (ht=0x80b4f48,
    apply_func=0x40510b40 <zend_restore_ini_entry_cb>,
    argument=0x8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:717
    #3 0x40510cdb in zend_ini_deactivate () at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:89
    #4 0x40510b40 in zend_remove_ini_entries (ini_entry=0x90,
    module_number=0x0)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:44

    This only happend at line 574 where we RESET all variables to default
    value.

    To solve this bug we must RESET all ini_entries to default values in
    send_php function. Maybe authors suggest better method to restore
    default values instead using zend_ini_deactivate(TSRMLS_C);

    ------------------------------------------------------------------------

    [2003-10-22 04:01:39] mattias at segerdahl dot info

    Sniper,

    I accidently ran into this bug a few moments ago. I talked to Derick
    about it in the channel and we agreed I would do some testing. There
    are some particular strange behaviour.

    I will try to explain as well as include the files needed to reproduce
    this error. But first let me point out one thing that I find really
    weird.

    This only occurs when the apache server has not been accessed for a
    while, if you reload the page directly after you've encountered this
    error message, it will work perfectly.

    The error message is:

    Warning: Unknown(): open_basedir restriction in effect.
    File(/var/www/users.bitcom.se/index.php) is not within the allowed
    path(s): (/var/www/www.sol.se) in Unknown on line 0
    Warning: Unknown(/var/www/users.bitcom.se/index.php): failed to open
    stream: Operation not permitted in Unknown on line 0
    Warning: (null)(): Failed opening '/var/www/users.bitcom.se/index.php'
    for inclusion (include_path='.:/usr/local/php//lib/php') in Unknown on
    line 0

    My php.ini file http://www.segerdahl.info/25753/php.ini
    My httpd.conf file http://www.segerdahl.info/25753/httpd.conf

    Server version: Apache/2.0.47
    Server built: Oct 20 2003 18:39:21

    PHP 4.3.4RC4 configured as:

    './configure' '--with-apxs2=/usr/local/httpd/bin/apxs'
    '--enable-mbstring' '--with-pear' '--with-mysql'
    '--enable-magic-quotes' '--with-ftp' '--sysconfdir=/etc/php'
    '--with-config-file-path=/etc/php' '--prefix=/usr/local/php/'
    '--enable-mbstring' '--with-curl' '--enable-ftp'

    APACHE configured as:
    ../configure --sysconfdir=/etc/httpd/conf --enable-ssl
    --prefix=/usr/local/httpd --enable-modules=dso,most

    Contact me on efnet if you need more information... // bad2da

    ------------------------------------------------------------------------

    [2003-10-04 18:58:16] net

    We do not know what causes this bug or how it can be reliably
    reproduced. If you know exactly HOW this can be reproduced, add the
    information here. Any other comments will be deleted.


    ------------------------------------------------------------------------

    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/25753

    --
    Edit this bug report at http://bugs.php.net/?id=25753&edit=1
    david Guest

  20. #20

    Default #25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

    ID: 25753
    Comment by: david at bizeweb dot com
    Reported By: net
    Status: Closed
    Bug Type: Apache related
    Operating System: *
    PHP Version: 4CVS, 5CVS
    New Comment:

    I found out that to use the CVS that you'll need to use .buildconf
    first. I had not done that. I have installed the cvs php properly now
    (I hope) and can not repeat the error. Sorry if I got anyone looking
    for something that wasn't there.


    Previous Comments:
    ------------------------------------------------------------------------

    [2004-02-02 08:25:48] david at bizeweb dot com

    I a related problem to an apache list, and someone directed me to here.
    I thought timing was so perfect and that the problem was fixed.
    However, I think this bug still exists. Unless I need to install a
    specific CVS version. I have php4-STABLE-200402012230 installed on a
    RH9 with apache2.0.44 with a php config of
    CFLAGS="-I/usr/kerberos/include -DSECURITY_HOLE_PASS_AUTHORIZATION"
    ../configure --with-apxs2=/usr/local/apache/bin/apxs --with-gettext
    --with-imap=/dl/imap-2001a --with-kerberos --with-glibcc --with-xml
    --with-mysql.

    I've isolated my server and in my httpd.conf have set the following for
    easy testing.
    StartServers 1
    MinSpareServers 1
    MaxSpareServers 2

    <VirtualHost x.x.x.x:80>
    ServerName foo.com
    </VirtualHost>

    <VirtualHost x.x.x.x:80>
    php_admin_flag engine off
    ServerName foo2.com
    </VirtualHost>
    I can keep going to foo.com without any problems as soon as I goto
    foo2.com, then foo.com will attempt to dl the php files.
    I'm new to this field, but if I can help just ask.

    ------------------------------------------------------------------------

    [2004-01-28 12:40:04] net

    This only happens on text/html files with the executable bit set. If
    the +x bit is set, we load the current ini settings and if php's
    xbithack option is not set we decline the request but forget to reset
    the ini settings potentially leaking them to the next request. This is
    now fixed in CVS and will be in the next release of both PHP4 and PHP5.

    ------------------------------------------------------------------------

    [2004-01-28 00:47:04] rover at tob dot ru

    We examine source files more carefull and remake a patch:

    diff -udr php-4.3.3/sapi/apache/mod_php4.c
    php-4.3.3.patched/sapi/apache/mod_php4.c
    --- php-4.3.3/sapi/apache/mod_php4.c 2003-06-03 11:41:49.000000000
    +0600
    +++ php-4.3.3.patched/sapi/apache/mod_php4.c 2004-01-28
    10:48:27.000000000 +0500
    -830,6 +830,9
    }
    if(!AP(xbithack)) {
    r->allowed |= (1 << METHODS) - 1;
    + zend_try {
    + zend_ini_deactivate(TSRMLS_C);
    + } zend_end_try();
    return DECLINED;
    }
    return send_pd_php(r);

    ------------------------------------------------------------------------

    [2004-01-27 13:36:14] rover at tob dot ru

    It seems we have found a bug in mod_php4.c. We can 100% reproduce this
    error. How to reproduce (our case):
    in httpd.conf we have:

    # to enable only one instance of apache process
    StartServers 1
    MaxClients 1
    #
    <Directory /var/www/info/>
    php_value engine off
    </Directory>

    in php.ini:
    Engine = On,
    we enable php-scripts at all site, but disable in /info.

    Let's begin:
    #/usr/sbin/apache.dbg -f /etc/apache/httpd.conf
    #gbd /usr/sbin/apache.gdb pid_of_child (attach to child, what serve
    requests)
    (gdb)p php_apache_info.engine
    =1 ! php-engine ENABLED
    (gdb)watch php_apache_info.engine ! VERY IMPORTANT
    (gdb)break send_php ! bug in this func.
    (gdb)c

    1) Request a usual file from http://our.site/info/index.html:
    Because we define 'php_value off' for this directory - at line 829 in
    function php_xbithack_handler(remember - we process text/html) we call
    zend_hash_apply((HashTable *) per_dir_conf, (apply_func_t)
    php_apache_alter_ini_entries TSRMLS_CC);
    and change our 'engine' value to 0.
    backtrace for this call (don't look at line number - they shifted
    because i insert debug lines in source files):
    Hardware watchpoint 1: php_apache_info.engine
    Old value = 1
    New value = 0
    #0 OnUpdateInt (entry=0x80dc778, new_value=0x80d3cc4 "off",
    new_value_length=3, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=4) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    #1 0x4051110a in zend_alter_ini_entry (name=0x80de170 "engine",
    name_length=7, new_value=0x80de180 "off",
    new_value_length=3, modify_type=2, stage=4) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:212
    #2 0x40519fc6 in php_apache_alter_ini_entries
    (per_dir_entry=0x812c598)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:511
    #3 0x4050b8f9 in zend_hash_apply (ht=0x809fc98, apply_func=0x40519f40
    <php_apache_alter_ini_entries>)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:698
    #4 0x4051ad1b in php_xbithack_handler (r=0x81367ec)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:850
    #5 0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
    #6 0x08067e28 in process_request_internal (r=0x81367ec) at
    http_request.c:1332
    #7 0x08067fd4 in ap_process_request (r=0x81367ec) at
    http_request.c:1348
    #8 0x08060644 in child_main (child_num_arg=0) at http_main.c:4719
    #9 0x080607f7 in make_child (s=0x0, slot=0, now=0) at
    http_main.c:4898
    #10 0x08060920 in startup_children (number_to_start=1) at
    http_main.c:4925
    #11 0x0806149a in standalone_main (argc=1, argv=0xbffffdf4) at
    http_main.c:5244
    #12 0x08061a08 in main (argc=1, argv=0xbffffdf4) at http_main.c:5601

    Result of 1): we process http://our.site/info/index.html succefull and
    set global var 'engine'=0!

    Now we try to access http://our.site/index.php
    2) breakpoint 2 executed:
    Breakpoint 2, send_php (r=0x81367ec, display_source_mode=0,
    filename=0x0)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:544
    544 fh.free_filename = 0;
    #0 send_php (r=0x81367ec, display_source_mode=0, filename=0x0)
    at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:544
    #1 0x4051a6eb in send_pd_php (r=0x81367ec) at
    /usr/local/src/apache2+php4/php4-4.3.3/sapi/apache/mod_php4.c:655
    #2 0x080551c3 in ap_invoke_handler (r=0x81367ec) at http_config.c:518
    #3 0x08067e28 in process_request_internal (r=0x81367ec) at
    http_request.c:1332
    #4 0x08067fd4 in ap_process_request (r=0x81367ec) at
    http_request.c:1348
    #5 0x08060644 in child_main (child_num_arg=135489516) at
    http_main.c:4719
    #6 0x080607f7 in make_child (s=0x81367ec, slot=0, now=135489516) at
    http_main.c:4898
    #7 0x08060920 in startup_children (number_to_start=1) at
    http_main.c:4925
    #8 0x0806149a in standalone_main (argc=1, argv=0xbffffdf4) at
    http_main.c:5244
    #9 0x08061a08 in main (argc=1, argv=0xbffffdf4) at http_main.c:5601

    But look at 'engine' - IT HAVE OLD VALUE = 0! What happend next:

    In mod_php4.c at line 570(original file from 4.3.3,4.3.4,4.3.5RC1) we
    have:
    if (!AP(engine)) {
    r->content_type = php_apache_get_default_mimetype(r
    TSRMLS_CC);
    r->allowed |= (1 << METHODS) - 1;
    zend_try {
    zend_ini_deactivate(TSRMLS_C);
    } zend_end_try();
    return DECLINED;
    }

    and instead serve index.php as x-application-php we only return
    DECLINE. Continue:

    3)(gdb)c
    Hardware watchpoint 1: php_apache_info.engine
    Old value = 0
    New value = 1
    OnUpdateInt (entry=0x80dc778, new_value=0x80b53e0 "1",
    new_value_length=1, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    453
    1: php_apache_info = {engine = 1, last_modified = 0, xbithack = 0,
    terminate_child = 0, in_request = 0 '\0'}
    (gdb) bt
    #0 OnUpdateInt (entry=0x80dc778, new_value=0x80b53e0 "1",
    new_value_length=1, mh_arg1=0x0, mh_arg2=0x4057f92c,
    mh_arg3=0x0, stage=8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:453
    #1 0x40510bcf in zend_restore_ini_entry_cb (ini_entry=0x80dc778,
    stage=8)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:51
    #2 0x4050b990 in zend_hash_apply_with_argument (ht=0x80b4f48,
    apply_func=0x40510b40 <zend_restore_ini_entry_cb>,
    argument=0x8) at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_hash.c:717
    #3 0x40510cdb in zend_ini_deactivate () at
    /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:89
    #4 0x40510b40 in zend_remove_ini_entries (ini_entry=0x90,
    module_number=0x0)
    at /usr/local/src/apache2+php4/php4-4.3.3/Zend/zend_ini.c:44

    This only happend at line 574 where we RESET all variables to default
    value.

    To solve this bug we must RESET all ini_entries to default values in
    send_php function. Maybe authors suggest better method to restore
    default values instead using zend_ini_deactivate(TSRMLS_C);

    ------------------------------------------------------------------------

    [2003-10-22 04:01:39] mattias at segerdahl dot info

    Sniper,

    I accidently ran into this bug a few moments ago. I talked to Derick
    about it in the channel and we agreed I would do some testing. There
    are some particular strange behaviour.

    I will try to explain as well as include the files needed to reproduce
    this error. But first let me point out one thing that I find really
    weird.

    This only occurs when the apache server has not been accessed for a
    while, if you reload the page directly after you've encountered this
    error message, it will work perfectly.

    The error message is:

    Warning: Unknown(): open_basedir restriction in effect.
    File(/var/www/users.bitcom.se/index.php) is not within the allowed
    path(s): (/var/www/www.sol.se) in Unknown on line 0
    Warning: Unknown(/var/www/users.bitcom.se/index.php): failed to open
    stream: Operation not permitted in Unknown on line 0
    Warning: (null)(): Failed opening '/var/www/users.bitcom.se/index.php'
    for inclusion (include_path='.:/usr/local/php//lib/php') in Unknown on
    line 0

    My php.ini file http://www.segerdahl.info/25753/php.ini
    My httpd.conf file http://www.segerdahl.info/25753/httpd.conf

    Server version: Apache/2.0.47
    Server built: Oct 20 2003 18:39:21

    PHP 4.3.4RC4 configured as:

    './configure' '--with-apxs2=/usr/local/httpd/bin/apxs'
    '--enable-mbstring' '--with-pear' '--with-mysql'
    '--enable-magic-quotes' '--with-ftp' '--sysconfdir=/etc/php'
    '--with-config-file-path=/etc/php' '--prefix=/usr/local/php/'
    '--enable-mbstring' '--with-curl' '--enable-ftp'

    APACHE configured as:
    ../configure --sysconfdir=/etc/httpd/conf --enable-ssl
    --prefix=/usr/local/httpd --enable-modules=dso,most

    Contact me on efnet if you need more information... // bad2da

    ------------------------------------------------------------------------

    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/25753

    --
    Edit this bug report at http://bugs.php.net/?id=25753&edit=1
    david Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. #6374 [Csd]: include_path in .htaccess accross multiple vhosts
    By sniper@php.net in forum PHP Development
    Replies: 2
    Last Post: January 28th, 07:32 PM
  2. Replies: 3
    Last Post: January 7th, 12:39 PM
  3. Replies: 0
    Last Post: October 4th, 04:58 AM
  4. Replies: 0
    Last Post: October 4th, 04:51 AM
  5. Use of php_value in .htaccess is not working
    By Jr in forum PHP Development
    Replies: 0
    Last Post: September 4th, 07:40 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139