Hi,
On Sun, 26 Mar 2006 12:42:57 -0500, in php.internals [EMAIL PROTECTED]
(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 h
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 [EMAIL PROTECTED]
(Ilia Al
On Sat, 25 Mar 2006 12:14:52 -0500, in php.internals [EMAIL PROTECTED]
(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
<[EMAIL PROTECTED]> ?
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
ope
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 mo
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 wri
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 alre
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 y
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_fil
>
> 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)
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 direc
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
ope
12 matches
Mail list logo
