Everything

php

open_basedir_for_include

php.internals

Sara Golemon

20 years ago

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

Rasmus Lerdorf

20 years ago

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

Jared Williams

20 years ago

>
> 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.

Any reason why can't set open_basedir programmatically? Obviously to only a subset of the current setting.

Jared

Ilia A.

20 years ago

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:

Rasmus Lerdorf

20 years ago

But it does prevent writing to those dirs.

Ilia Alshanetsky wrote:

Ilia A.

20 years ago

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

Rasmus Lerdorf

20 years ago

Ilia Alshanetsky wrote:

> 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.

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

Ilia A.

20 years ago

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

Peter Brodersen

20 years ago

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

Ilia A.

20 years ago

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:

Peter Brodersen

20 years ago

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

Sara Golemon

20 years ago

>> 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.
>>
> 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