php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #77979 open_basedir deprecation
Submitted: 2019-05-07 10:47 UTC Modified: 2019-05-08 09:17 UTC
From: spam2 at rhsoft dot net Assigned:
Status: Not a bug Package: Safe Mode/open_basedir
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: spam2 at rhsoft dot net
New email:
PHP Version: OS:

Further comment on this bug is unnecessary.

 

 [2019-05-07 10:47 UTC] spam2 at rhsoft dot net
Description:
------------
can you guys please step back from trying to remove everything left and right in PHP 8.0? 

everybody knows that it's not bullet proof but it has it's value

the performance penalty is only because of the hardcoded nonsense instead a ini-option we patch out of PHP because with disable_functions="symlink" the race can't happen

until you fix the design of realpath cache it's worthless anyways
https://bugs.php.net/bug.php?id=73888

-------- Weitergeleitete Nachricht --------
Betreff: [PHP-DEV] open_basedir?
Datum: Tue, 7 May 2019 12:11:03 +0200
Von: Nikita Popov <nikita.ppv@gmail.com>
An: PHP internals <internals@lists.php.net>

Hi internals,

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 "best effort" mechanism, with known
workarounds and more regularly being found. Especially when it comes to
interactions with 3rd party libraries, enforcing open_basedir is simply
impossible.

What open_basedir tries to do must be implemented on the operating system
level to work reliably (and of course such mechanisms exist, such as jails,
chroot and friends).

I wonder if it is feasible to drop this ini setting? Enforcing this doesn't
really seem like any of PHP's business. If not, I think we need to at least


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-05-07 18:04 UTC] cmb@php.net
-Status: Open +Status: Not a bug -Type: Security +Type: Bug -Package: *General Issues +Package: Safe Mode/open_basedir
 [2019-05-07 18:04 UTC] cmb@php.net
Sigh
 [2019-05-08 09:16 UTC] spam2 at rhsoft dot net
yeah, sigh

https://bugs.php.net/bug.php?id=73888

until that is fixed the whole realpath cache is useless and dangerous because clearstatcache() only affects the worker process which replaced the file and requests served by exatcly that process while other workers still have their autistic cache with no programmatic way to fix it 

it makes no sense at all that every php process maintains it's own authistic cache
 [2019-05-08 09:17 UTC] nikic@php.net
-Block user comment: No +Block user comment: Yes
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 00:01:29 2024 UTC