On 12.07.2021 at 15:54, Nikita Popov wrote:
> On Thu, Jul 8, 2021 at 11:34 PM Stanislav Malyshev
> wrote:
>
>>> Apparently, there has been no resolution for this issue so far. While I
>>> don't really care about the open_basdedir directive per se, I fully
>>> agree that we should not advertize
On Thu, Jul 8, 2021 at 11:34 PM Stanislav Malyshev
wrote:
> Hi!
>
> > Apparently, there has been no resolution for this issue so far. While I
> > don't really care about the open_basdedir directive per se, I fully
> > agree that we should not advertize it as security feature, and to
> > clearly
Hi!
Apparently, there has been no resolution for this issue so far. While I
don't really care about the open_basdedir directive per se, I fully
agree that we should not advertize it as security feature, and to
clearly state this in the PHP manual, as well as in our security policy.
Correct.
On 07.05.2019 at 12:11, Nikita Popov wrote:
> The open_basedir ini setting has two significant problems:
>
> 1. It is a major performance hit, because it disables the realpath cache.
>
> 2. Many people think it is a security feature and use it as such. However,
> open_basedir is in reality a
Nathan Rixham wrote:
Hi All,
Figured this was for internals before opening up a bug report.
In php 5.2.8 on windows and linux (only ones tested so far)
when you add in a value to open_basedir in either php.ini or a
vhosts.conf file; *relative* paths suddenly do not work for the
php_value
Nathan Rixham wrote:
with php.ini/vhosts.conf open_basedir set
these values in .htaccess WILL NOT work
php_flag log_errors on
php_value error_log logfile.txt
these values in vhosts.conf WILL work
php_flag log_errors on
php_value error_log logfile.txt
absolute paths to the same
Jani Taskinen wrote:
Nathan Rixham wrote:
with php.ini/vhosts.conf open_basedir set
these values in .htaccess WILL NOT work
php_flag log_errors on
php_value error_log logfile.txt
these values in vhosts.conf WILL work
php_flag log_errors on
php_value error_log logfile.txt
Nathan Rixham wrote:
Jani Taskinen wrote:
Nathan Rixham wrote:
with php.ini/vhosts.conf open_basedir set
these values in .htaccess WILL NOT work
php_flag log_errors on
php_value error_log logfile.txt
these values in vhosts.conf WILL work
php_flag log_errors on
php_value error_log logfile.txt
well, in case there are no objections I will remove special treatment
of /tmp path in sessions code of 5.3 and 6.0
should 5.2 also be fixed?
On Wed, Aug 27, 2008 at 12:30 PM, Alexey Zakhlestin [EMAIL PROTECTED] wrote:
ext/sessions/mod_files.c:281 has a hardcoded openbasedir-check
skipping of
well, in case there are no objections I will remove special treatment
of /tmp path in sessions code of 5.3 and 6.0
should 5.2 also be fixed?
i would not put this into 5.2 this late into the lifetime of this branch.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To
Hello,
On 10/13/06, Tim Starling [EMAIL PROTECTED] wrote:
Sara Golemon wrote:
The attached patch changes open_basedir from PHP_INI_SYSTEM to PHP_INI_ALL.
[...]
The advantage of doing this is that package authors and/or users of shared
hosting who may not have access to making their settings
Hi,
Great feature. I can see this being very useful to packaged
PHP applications
like ours (MediaWiki). The only complication in
implementation I can think
of is trying to work out the location of PEAR, for those
modules that use
it. I suppose we would have to append the default
Pierre wrote:
There is no issue with PEAR or any applications using include_path and
relative paths in include/require. The system include_path, if any,
paths should already be in the open_basedir. If they are not, you
have to install the desired modules within your open_basedir, just
like now.
Tim Starling wrote:
Pierre wrote:
There is no issue with PEAR or any applications using include_path and
relative paths in include/require. The system include_path, if any,
paths should already be in the open_basedir. If they are not, you
have to install the desired modules within your
Hello,
On 10/13/06, Gregory Beaver [EMAIL PROTECTED] wrote:
Tim Starling wrote:
Pierre wrote:
There is no issue with PEAR or any applications using include_path and
relative paths in include/require. The system include_path, if any,
paths should already be in the open_basedir. If they are
Sara Golemon wrote:
The attached patch changes open_basedir from PHP_INI_SYSTEM to PHP_INI_ALL.
[...]
The advantage of doing this is that package authors and/or users of shared
hosting who may not have access to making their settings more restrictive
can avoid most simple FS inspection
Can someone tell me what I'm doing wrong here? I'm using PHP 4.3.11 on
Red Hat 5.0 (Cobalt). /home/sites/www.harvardchemclub.org is a symbolic
link that points to /home/sites/site66. I've tried this with and without
trailing slashes. I added a comment to a similar bug report years ago,
Sara,
The output is:
/home/sites/site66/web/index.html
Thanks,
Aaron
Aaron Greenspan
President CEO
Think Computer Corporation
http://www.thinkcomputer.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 14.09.2005 22:37, Aaron Greenspan wrote:
Sara,
The output is:
/home/sites/site66/web/index.html
I guess this is the answer:
All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink.
(c)
Antony,
I'm not trying to avoid the restriction by using a symbolic link. I'm
trying to enforce it, yet regardless of whether I put any of the
following in my allowed path:
/home/sites/site66
/home/sites/site66/
/home/sites/site66/web
/home/sites/site66/web/
20 matches
Mail list logo
