Req #62509 [Com]: chroot() is disabled with ZTS enabled
| From: | streaky at mybrokenlogic dot com | Date: | Mon, 09 Jul 2012 15:10:39 +0000 |
| Subject: | Req #62509 [Com]: chroot() is disabled with ZTS enabled | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-171828@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=62509&edit=1
ID: 62509
Comment by: streaky at mybrokenlogic dot com
Reported by: streaky at mkybrokenlogic dot com
Summary: chroot() is disabled with ZTS enabled
Status: Not a bug
Type: Feature/Change Request
Package: Directory function related
Operating System: Anything but windows?
PHP Version: Irrelevant
Block user comment: N
Private report: N
New Comment:
There are situations where you need to regardless - for example runkit needs ZTS - if you need
runkit and chroot() currently you can't do it without the aforementioned hack. Besides this
*is* a threaded context.
There's no good thread safety reason why chroot() would be disabled besides the "it's
hard to get it to configure like that" is there? I'm okay with the way it is just in
principle it seems wrong to me - personally I can do it in a patch...
Previous Comments:
------------------------------------------------------------------------
[2012-07-09 05:29:27] laruence@php.net
maybe we can always return false in ZTS build, and trigger a warning.
------------------------------------------------------------------------
[2012-07-08 21:02:35] johannes@php.net
You shouldn't use ZTS binaries in non-threaded context. They need more memory, they are slower,
they are harder to debug in case of critical errors.
That aside: We have no good mechanism to disable it easily in one context only.
------------------------------------------------------------------------
[2012-07-08 17:00:46] streaky at mkybrokenlogic dot com
Description:
------------
chroot() seems to be arbitrarily disabled with ZTS enabled. It seems like it is disabled because
when ZTS is -usually- used it is with a sapi that requires thread safety but this isn't always
the case.
AFAIK there isn't a good reason for it, I assume it's some sort of oversight - a cheap and
cheerful way to achieve the above, but it doesn't account for all circumstances so you have to
go hacking on the source code in about 3 different places.
It probably should be as is *except* for if CLI and possibly CGI is the SAPI.
Test script:
---------------
<?php
var_dump(chroot("/chroot/me/here/"));
Expected result:
----------------
bool(true)
Actual result:
--------------
Fatal error: Call to undefined function chroot()
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=62509&edit=1