# open_basedir_for_include - Thread: https://externals.io/message/22572 - Original archive: https://news-web.php.net/php.internals/22572 - Started by Sara Golemon on 2006-03-25T03:32:56+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #22572 — Sara Golemon — 2006-03-25T03:32:56+00:00 URL: https://externals.io/message/22572#22572 The PDM recommendation covering the removal of safe_mode included a note on expanding the role of open_basedir. To that end, I'd like to propose introducing a new ini option: open_basedir_for_include which would allow using include/require(_once) on an expanded set of directories than what open_basedir would otherwise allow. Since php_fopen_wrapper_for_zend() specifies STREAM_OPEN_FOR_INCLUDE, we can catch this option in the plain_files wrapper and expand the open_basedir check to allow specifying the alternate INI option (when set of course). Obviously if this new option were left unset and the regular open_basedir were set, we'd still use that for full BC. If noone objects I'll add this functionality in between unicode related patches in a week or so. -Sara --- ## #22574 — Rasmus Lerdorf — 2006-03-25T08:23:41+00:00 URL: https://externals.io/message/22572#22574 · In reply to: #22572 Sara Golemon wrote: > The PDM recommendation covering the removal of safe_mode included a note > on expanding the role of open_basedir. To that end, I'd like to propose > introducing a new ini option: open_basedir_for_include which would allow > using include/require(_once) on an expanded set of directories than what > open_basedir would otherwise allow. > > Since php_fopen_wrapper_for_zend() specifies STREAM_OPEN_FOR_INCLUDE, we > can catch this option in the plain_files wrapper and expand the > open_basedir check to allow specifying the alternate INI option (when > set of course). Obviously if this new option were left unset and the > regular open_basedir were set, we'd still use that for full BC. > > If noone objects I'll add this functionality in between unicode related > patches in a week or so. Sounds like a good idea to me. A very handy use of open_basedir that is often overlooked is as a way to protect you from yourself. That is, you define up front where you know your application should be reading and writing from and if you happen to make a mistake in your code it will act as a safety net. Adding the ability to include files from common include directories without adding them to the list of real open_basedir directories makes this more useful. -Rasmus --- ## #22578 — Ilia Alshanetsky — 2006-03-25T16:51:44+00:00 URL: https://externals.io/message/22572#22578 · In reply to: #22572 Why not just add the dirs you intend to include from to open_basedir directly? It does not prevent arbitrary files from being loaded anyway from those dirs. A simple `ob_start()` include "file"; `ob_get_clean()` will happily give you the data. And if you wanted to see the source code, `highlight_file()` could be used. Ilia Sara Golemon wrote: > The PDM recommendation covering the removal of safe_mode included a note > on expanding the role of open_basedir. To that end, I'd like to propose > introducing a new ini option: open_basedir_for_include which would allow > using include/require(_once) on an expanded set of directories than what > open_basedir would otherwise allow. > > Since php_fopen_wrapper_for_zend() specifies STREAM_OPEN_FOR_INCLUDE, we > can catch this option in the plain_files wrapper and expand the > open_basedir check to allow specifying the alternate INI option (when > set of course). Obviously if this new option were left unset and the > regular open_basedir were set, we'd still use that for full BC. > > If noone objects I'll add this functionality in between unicode related > patches in a week or so. > > -Sara --- ## #22579 — Rasmus Lerdorf — 2006-03-25T16:55:57+00:00 URL: https://externals.io/message/22572#22579 · In reply to: #22578 But it does prevent writing to those dirs. Ilia Alshanetsky wrote: > Why not just add the dirs you intend to include from to open_basedir > directly? It does not prevent arbitrary files from being loaded anyway > from those dirs. A simple `ob_start()` include "file"; `ob_get_clean()` will > happily give you the data. And if you wanted to see the source code, > `highlight_file()` could be used. > > Ilia > > Sara Golemon wrote: > > […] --- ## #22580 — Ilia Alshanetsky — 2006-03-25T17:01:24+00:00 URL: https://externals.io/message/22572#22580 · In reply to: #22579 Rasmus Lerdorf wrote: > But it does prevent writing to those dirs. That should be the job of file permissions, let's use PEAR directory as an example. In normal circumstances only the root user can write to those dirs and everyone else has read-only access, therefor write permission would already be denied to those users. Ilia --- ## #22581 — Rasmus Lerdorf — 2006-03-25T17:03:43+00:00 URL: https://externals.io/message/22572#22581 · In reply to: #22580 Ilia Alshanetsky wrote: > Rasmus Lerdorf wrote: > > […] > > That should be the job of file permissions, let's use PEAR directory as > an example. In normal circumstances only the root user can write to > those dirs and everyone else has read-only access, therefor write > permission would already be denied to those users. Yes, and in normal circumstances you wouldn't accidentally write to places you aren't supposed to, just like in normal circumstances you will have all your file permissions set correctly. And in normal circumstances you would never have bugs in your code. -Rasmus --- ## #22582 — Ilia Alshanetsky — 2006-03-25T17:14:52+00:00 URL: https://externals.io/message/22572#22582 · In reply to: #22581 Rasmus Lerdorf wrote: > Yes, and in normal circumstances you wouldn't accidentally write to > places you aren't supposed to, just like in normal circumstances you > will have all your file permissions set correctly. And in normal > circumstances you would never have bugs in your code. Attempts to modify common include files are not very likely to be accidental. It is a bit hard to confuse include() with `file_put_contents()` ;-) Plus is you leave the file writable, what's to say you couldn't do: shell_exec("cp foo /lib/file/inc.php") ? Ilia --- ## #22583 — Sara Golemon — 2006-03-26T01:59:41+00:00 URL: https://externals.io/message/22572#22583 · In reply to: #22578 > > […] > Why not just add the dirs you intend to include from to open_basedir > directly? It does not prevent arbitrary files from being loaded anyway > from those dirs. A simple `ob_start()` include "file"; `ob_get_clean()` will > happily give you the data. And if you wanted to see the source code, > `highlight_file()` could be used. > Well, my thoughts were from a shared server perspective where some data resources might want to be made available on a limited (access controlled) basis though a set of wrapper methods that scripts written by third parties could call without being able to see the insides of. The example of `highlight_file()` (and similar approaches like `token_get_all()`) and of course the classic open_basedir defying `exec()` approach are workaroundable of course, but mentioning them makes me realize that something as simple as include('php://filter/string.base64-encode/resource=/includedir/script.php'); could be used to dump the contents which could then be decoded to see the original version. This can also be worked around, but the availability of these kinds of sneak-abouts just highlights the fact that what I'm trying to accomplish won't be handled by this sort of approach in an effective manner. Anyrate. The idea isn't going to work as a security solution. Might give some aid for preventing accidental mess-ups as Rasmus pointed out, but it's not an effective counter-measure. Nevermind and carry on.... -Sara --- ## #22585 — Peter Brodersen — 2006-03-26T17:34:55+00:00 URL: https://externals.io/message/22572#22585 · In reply to: #22582 On Sat, 25 Mar 2006 12:14:52 -0500, in php.internals ilia@prohost.org (Ilia Alshanetsky) wrote: >Plus is you leave the file writable, what's to say you couldn't do: >shell_exec("cp foo /lib/file/inc.php") ? The possible exec restriction salvaged from safe_mode mentioned in <43874C56.8050007@lerdorf.com> ? This thread is mainly about a safety net for one's own code. But regarding restricting users, open_basedir is IMO useless if not backed up by some other methods (like restricting exec functions). -- - Peter Brodersen --- ## #22586 — Ilia Alshanetsky — 2006-03-26T17:42:57+00:00 URL: https://externals.io/message/22572#22586 · In reply to: #22585 If you don't trust your users to execute external commands, which is perfectly valid concern, PHP provides you with a way (disable_functions) INI setting to restrict the functionality. Ilia Peter Brodersen wrote: > On Sat, 25 Mar 2006 12:14:52 -0500, in php.internals ilia@prohost.org > (Ilia Alshanetsky) wrote: > > > […] > > The possible exec restriction salvaged from safe_mode mentioned in > <43874C56.8050007@lerdorf.com> ? > > This thread is mainly about a safety net for one's own code. But > regarding restricting users, open_basedir is IMO useless if not backed > up by some other methods (like restricting exec functions). --- ## #22587 — Peter Brodersen — 2006-03-26T19:14:45+00:00 URL: https://externals.io/message/22572#22587 · In reply to: #22586 Hi, On Sun, 26 Mar 2006 12:42:57 -0500, in php.internals ilia@prohost.org (Ilia Alshanetsky) wrote: >If you don't trust your users to execute external commands, which is >perfectly valid concern, PHP provides you with a way (disable_functions) > INI setting to restrict the functionality. I have earlier tried to ask for some "best practice" (e.g. <20051125105959.9876.PENGUIN@php.net> ). Honestly I don't think requiring admins with untrusted users (all web host companies) to maintain their own lists would be practical. Would you be able to easily compile that list of functions that should be included in the disabled_functions setting? It wouldn't be enough to just look at the functions mentioned at http://php.net/exec - you might miss other functions such as `popen()`. Unless I have missed part of the documentation the best page to look at for compiling the list of "dangerous"/exec related functions is http://php.net/manual/en/features.safe-mode.functions.php . Maybe this is just a documentation issue, but I believe the ability of disabling all exec functions in one easy way is pretty important for a bunch of administrators out there. Furthermore, this behaviour would be vulnerable to new exec-functions requiring a lot of maintenance for end users. At least Rasmus mentioned that he would appreciate being reminded of this feature (of keeping an internal list of exec functions and still use safe_mode_exec_dir - possibly under a more describing name) -- - Peter Brodersen