php-windows Digest 2 Feb 2006 18:07:20 -0000 Issue 2881
Topics (messages 26672 through 26677):
unexplicable crash?
26672 by: Egon Hilgenstieler
Cant write file to server
26673 by: Michael Adams
26677 by: El Bekko
Re: Question about directory & file operations
26674 by: GT
26675 by: Stut
26676 by: GT
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
Hi All,
I've been having a problem with a PHP script. It simply crashes with the
classic message "PHP.exe did a nasty thing and need to be closed bla
bla ...". No message in apache's log nor php's. It is a very complicated
script and has an extensive use of session (huge complex structure in
session) and database (odbc) access.
Sometimes it crashes and others it works fine. The probability of
crashing increases the more the application is used.
It crashes on both versions of PHP 4.3.4 and 4.4.3 and on apache 1.3 and
apache2. I've tested it on windows XP SP1 and windows 2000 server.
Apache module and CGI script. I've not seen it crash on linux.
Could it be an out of memory problem? How could I debug it? I've heard
that php.ini's memory_limit is useless in windows. I also do not have
the function memory_get_usage() defined.
Or perhaps there is a catch when overusing session data? Alternatives?
Where do I go from here? :( Any help would be greatly appreciated.
Thanks in advance.
Egon.
--- End Message ---
--- Begin Message ---
Newbie with Kiwiwebhost and LAMP with PHP 4.XX
Trying to iron out my first "file upload" issues. Using "Build your
own database driven websites: using PHP and MySQL" and the online
manual as main resources.
I cannot write out a file to my public_html directory. I have trimmed
this down to the bare minimum.
/*PHP*********************/
$destfilename = 'hello.txt';
$outputdata = 'Hello World!';
$destfile = fopen($destfilename, 'w');
if (!$destfile) {
exit ('Unable to open file for writing');
}
fwrite($destfile, $outputdata);
fclose($destfile);
echo 'Success';
/*EOF**********************/
In theory with relative addressing it should save the data to a file in
the same directory as the script (according to kiwiwebhost). Also they
say they do not block 'fopen'/'fwrite'. 'fread' works fine from the
temporary uploadfile.
I get this error...
Warning: fopen(hello.txt): failed to open stream: Permission denied in
/home/mbadams/public_html/rentals/fileupload.php on line 4.
Also tested:
.jpg for output file
copy function raises same error
absolute addressing
fopen ($destfilename, 'x');
I gotta be missing something simple here.
Don't ping me for the text file write. I will be using jpegs in
production. A simple text helps minimise my example.
TIA
--
Michael
--- End Message ---
--- Begin Message ---
Michael Adams wrote:
Newbie with Kiwiwebhost and LAMP with PHP 4.XX
Trying to iron out my first "file upload" issues. Using "Build your
own database driven websites: using PHP and MySQL" and the online
manual as main resources.
I cannot write out a file to my public_html directory. I have trimmed
this down to the bare minimum.
/*PHP*********************/
$destfilename = 'hello.txt';
$outputdata = 'Hello World!';
$destfile = fopen($destfilename, 'w');
if (!$destfile) {
exit ('Unable to open file for writing');
}
fwrite($destfile, $outputdata);
fclose($destfile);
echo 'Success';
/*EOF**********************/
In theory with relative addressing it should save the data to a file in
the same directory as the script (according to kiwiwebhost). Also they
say they do not block 'fopen'/'fwrite'. 'fread' works fine from the
temporary uploadfile.
I get this error...
Warning: fopen(hello.txt): failed to open stream: Permission denied in
/home/mbadams/public_html/rentals/fileupload.php on line 4.
Also tested:
.jpg for output file
copy function raises same error
absolute addressing
fopen ($destfilename, 'x');
I gotta be missing something simple here.
Don't ping me for the text file write. I will be using jpegs in
production. A simple text helps minimise my example.
TIA
Your folder/existing files permissions aren't set right ;) CHMOD them to
775
--- End Message ---
--- Begin Message ---
I found a much simpler way to handle this problem..
It's not pretty, but it's effective.
$path = $_GET["path"];
if( !isset( $path ) || $path == "" ) {
$path = "D:/FTPDIR";
}
$test = $path; // keep from mangling $path... For some reason, if I
did the test below using $path it caused problems further in the script.
if ($test = eregi(':$', $test) || eregi('^\..', $test) ||
eregi('^\/?\..', $test) ) {
$path = "D:/FTPDIR";
}
I tried it first with just the first eregi, and was only able to catch a
case where the user tried to
access with a URL like http://localhost/fileman.php?path=C:
It would still let you browse unwanted directories by doing
http://localhost/fileman.php?path=/../
so I added the second eregi and that stopped that... but...
http://localhost/fileman.php?path=/../../
would still get thru
the third eregi stopped that one... it seems that I have it fixed so that
only links I specify in the
script are able to be browsed.. Unless a person knows a particular
Directory.. But that can easiliy be
stopped by filtering known directories like C:/Windows with another eregi
Thanks advice guys... It got me thinkin.
"Stut" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Mike wrote:
>
>>>If it is called with the right parameters or the "Previous Directory"
>>>link is clicked too many times, the browser will be outside of the paths
>>>that I want them to be in...
>>>
>>>I would like to be able to lock the browser down to a particular set of
>>>directories and thier subs.
>>>
>>What you may want to do is set up a bit of parsing in your script so that
>>the script is passed the relative portion of the directory and the script
>>appends the parent folders to that.
>>For example, say the user is browsing directory
>>C:\users\tom\images\vacation
>>and you want to lock everything to the \users directory.
>>
>>Have the script expect
>>http://localhost/script.php?path=users\tom\images\vacation instead of the
>>full path. You can then do some basic string parsing to determine the
>>first
>>folder (in this case "users") and ensure that that matches a defined set
>>of
>>acceptable folders.
>>
>>So
>>if($first_dir != "users"){
>> echo "this is an invalid directory";
>>}
>>
>>Etc.
>>
>>Also, if someone tries to pass "C:\" into $path, it'd end up getting
>>parsed
>>as "C:\C:\", which will obviously be an invalid directory.
>>
>>This would allow the user from doing something like
>>http://localhost/script.php?path=windows\system32 since "windows" isn't in
>>the approved folders list.
>>
>>I'm sure there's a bunch of other ways of doing this, but it's the first
>>that popped into my head.
>>
> Please please please don't make this your only check. According to the
> above I could easily do something like the following to get where I wanted
> to go...
>
> http://localhost/script.php?path=users\..\..\..\..\..\windows\system32
>
>
> I suggest you look at http://php.net/realpath and use that to get the real
> absolute path after ..'s etc have been expanded, then compare that to the
> directory you want to lock them into.
>
> -Stut
--- End Message ---
--- Begin Message ---
GT wrote:
"Stut" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Mike wrote:
If it is called with the right parameters or the "Previous Directory"
link is clicked too many times, the browser will be outside of the paths
that I want them to be in...
I would like to be able to lock the browser down to a particular set of
directories and thier subs.
What you may want to do is set up a bit of parsing in your script so that
the script is passed the relative portion of the directory and the script
appends the parent folders to that.
For example, say the user is browsing directory
C:\users\tom\images\vacation
and you want to lock everything to the \users directory.
Have the script expect
http://localhost/script.php?path=users\tom\images\vacation instead of the
full path. You can then do some basic string parsing to determine the
first
folder (in this case "users") and ensure that that matches a defined set
of
acceptable folders.
So
if($first_dir != "users"){
echo "this is an invalid directory";
}
Etc.
Also, if someone tries to pass "C:\" into $path, it'd end up getting
parsed
as "C:\C:\", which will obviously be an invalid directory.
This would allow the user from doing something like
http://localhost/script.php?path=windows\system32 since "windows" isn't in
the approved folders list.
I'm sure there's a bunch of other ways of doing this, but it's the first
that popped into my head.
Please please please don't make this your only check. According to the
above I could easily do something like the following to get where I wanted
to go...
http://localhost/script.php?path=users\..\..\..\..\..\windows\system32
I suggest you look at http://php.net/realpath and use that to get the real
absolute path after ..'s etc have been expanded, then compare that to the
directory you want to lock them into.
-Stut
I found a much simpler way to handle this problem..
It's not pretty, but it's effective.
$path = $_GET["path"];
if( !isset( $path ) || $path == "" ) {
$path = "D:/FTPDIR";
}
$test = $path; // keep from mangling $path... For some reason, if I
did the test below using $path it caused problems further in the script.
if ($test = eregi(':$', $test) || eregi('^\..', $test) ||
eregi('^\/?\..', $test) ) {
$path = "D:/FTPDIR";
}
I tried it first with just the first eregi, and was only able to catch a
case where the user tried to
access with a URL like http://localhost/fileman.php?path=C:
It would still let you browse unwanted directories by doing
http://localhost/fileman.php?path=/../
so I added the second eregi and that stopped that... but...
http://localhost/fileman.php?path=/../../
would still get thru
the third eregi stopped that one... it seems that I have it fixed so that
only links I specify in the
script are able to be browsed.. Unless a person knows a particular
Directory.. But that can easiliy be
stopped by filtering known directories like C:/Windows with another eregi
Thanks advice guys... It got me thinkin.
I would still urge you to include the use of the realpath function. With
the various character encodings that are around realpath is the only way
to get the actual absolute path and it's that path you should be
checking not the one you've created from the incoming variables.
-Stut
--- End Message ---
--- Begin Message ---
I'll have a peek at it..
"Stut" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> GT wrote:
>
>>"Stut" <[EMAIL PROTECTED]> wrote in message
>>news:[EMAIL PROTECTED]
>>
>>>Mike wrote:
>>>
>>>
>>>>>If it is called with the right parameters or the "Previous Directory"
>>>>>link is clicked too many times, the browser will be outside of the
>>>>>paths that I want them to be in...
>>>>>
>>>>>I would like to be able to lock the browser down to a particular set of
>>>>>directories and thier subs.
>>>>>
>>>>>
>>>>What you may want to do is set up a bit of parsing in your script so
>>>>that
>>>>the script is passed the relative portion of the directory and the
>>>>script
>>>>appends the parent folders to that.
>>>>For example, say the user is browsing directory
>>>>C:\users\tom\images\vacation
>>>>and you want to lock everything to the \users directory.
>>>>
>>>>Have the script expect
>>>>http://localhost/script.php?path=users\tom\images\vacation instead of
>>>>the
>>>>full path. You can then do some basic string parsing to determine the
>>>>first
>>>>folder (in this case "users") and ensure that that matches a defined set
>>>>of
>>>>acceptable folders.
>>>>
>>>>So
>>>>if($first_dir != "users"){
>>>> echo "this is an invalid directory";
>>>>}
>>>>
>>>>Etc.
>>>>
>>>>Also, if someone tries to pass "C:\" into $path, it'd end up getting
>>>>parsed
>>>>as "C:\C:\", which will obviously be an invalid directory.
>>>>
>>>>This would allow the user from doing something like
>>>>http://localhost/script.php?path=windows\system32 since "windows" isn't
>>>>in
>>>>the approved folders list.
>>>>
>>>>I'm sure there's a bunch of other ways of doing this, but it's the first
>>>>that popped into my head.
>>>>
>>>>
>>>Please please please don't make this your only check. According to the
>>>above I could easily do something like the following to get where I
>>>wanted to go...
>>>
>>>http://localhost/script.php?path=users\..\..\..\..\..\windows\system32
>>>
>>>
>>>I suggest you look at http://php.net/realpath and use that to get the
>>>real absolute path after ..'s etc have been expanded, then compare that
>>>to the directory you want to lock them into.
>>>
>>>-Stut
>>I found a much simpler way to handle this problem..
>>
>>It's not pretty, but it's effective.
>>
>> $path = $_GET["path"];
>> if( !isset( $path ) || $path == "" ) {
>> $path = "D:/FTPDIR";
>> }
>> $test = $path; // keep from mangling $path... For some reason, if
>> I did the test below using $path it caused problems further in the
>> script.
>>
>> if ($test = eregi(':$', $test) || eregi('^\..', $test) ||
>> eregi('^\/?\..', $test) ) {
>> $path = "D:/FTPDIR";
>> }
>>
>>I tried it first with just the first eregi, and was only able to catch a
>>case where the user tried to
>>access with a URL like http://localhost/fileman.php?path=C:
>>
>>It would still let you browse unwanted directories by doing
>> http://localhost/fileman.php?path=/../
>>
>>so I added the second eregi and that stopped that... but...
>>
>> http://localhost/fileman.php?path=/../../
>>
>>would still get thru
>>
>>the third eregi stopped that one... it seems that I have it fixed so that
>>only links I specify in the
>>script are able to be browsed.. Unless a person knows a particular
>>Directory.. But that can easiliy be
>>stopped by filtering known directories like C:/Windows with another eregi
>>
>>Thanks advice guys... It got me thinkin.
>>
> I would still urge you to include the use of the realpath function. With
> the various character encodings that are around realpath is the only way
> to get the actual absolute path and it's that path you should be checking
> not the one you've created from the incoming variables.
>
> -Stut
--- End Message ---
