Jump to content

Unable to write/append but no error message (IIS7/php5.3)


Recommended Posts

Hello,

 

I tried installing a test environment on my laptop today. I'm running IIS7 with php 5.3 on 32bit Vista Premium. PHP seems to be working fine but I had some silent error when trying to set-up phpMyAdmin. After some nosing around I found that the problem was that I could not write/append to files, but without getting any error messages. That is, I can open a stream, get a valid resource id, but when I try doing fprintf nothing happens. I thought it was a permission issue but even after I gave full control to everybody, the issue persisted. Any suggestions how I can debug this?

 

Thanks,

 

Ilya

do you defiantly have

do you defiantly have error_reporting set to a high enough level and display_errors set to On ?

 

It's very strange for php to fail and not tell you why.

set to a high enough level and display_errors set to On ?

 

It's very strange for php to fail and not tell you why.

 

error_reporting was set to all, but display_errors was off, my fault. I turned display_errors on and got the following message when trying to run phpMyAdmin:

 

Warning: Unknown: open(C:\Windows\Temp\sess_p2senobmer8ld3eb4kv35dc6r5h4uca1, O_RDWR) failed: Permission denied (13) in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (C:\Windows\Temp) in Unknown on line 0

 

My previous test with writing files now seems to work. What's weird is that it stated working after I used opendir/readdir. I used this command once and like magic files started appearing ever since. Perhaps some bug with FastCGI/IIS 7? Who knows... I'll try changing permissions with Temp...

do you defiantly have

do you defiantly have error_reporting set to a high enough level and display_errors set to On ?

 

It's very strange for php to fail and not tell you why.

set to a high enough level and display_errors set to On ?

 

It's very strange for php to fail and not tell you why.

 

error_reporting was set to all, but display_errors was off, my fault. I turned display_errors on and got the following message when trying to run phpMyAdmin:

 

Warning: Unknown: open(C:\Windows\Temp\sess_p2senobmer8ld3eb4kv35dc6r5h4uca1, O_RDWR) failed: Permission denied (13) in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (C:\Windows\Temp) in Unknown on line 0

 

My previous test with writing files now seems to work. What's weird is that it stated working after I used opendir/readdir. I used this command once and like magic files started appearing ever since. Perhaps some bug with FastCGI/IIS 7? Who knows... I'll try changing permissions with Temp...

 

 

Ok, problem "solved" by giving Users full control over C:/Windows/Temp

 

But this seems like a rather inherently unsafe solution. Giving IIS_USER full control was insufficient so I'm wondering how else I can limit permissions without killing everything.

Do you have IIS impersonating a different user than IUSR_ when working with phpMyAdmin?  Maybe you just need to add permissions for a different user account or group.

 

But giving additional permissions to c:\windows\temp shouldn't be much of a risk, it's not a URL that's accessible from a user's browser.

 

Do you have IIS impersonating a different user than IUSR_ when working with phpMyAdmin?  Maybe you just need to add permissions for a different user account or group.

 

But giving additional permissions to c:\windows\temp shouldn't be much of a risk, it's not a URL that's accessible from a user's browser.

 

 

No, but it's an easy place for an activeX component to download an executable  to and, if users are allowed to execute from it, then it can execute that executable launching a virus. What I'm saying is that it is a vulnerability for me the computer user (since this is a personal computer) although since most people don't have this vulnerability then perhaps there are no/few viruses exploiting it and probability of me hitting it is low. I seem to remember that IIS is impersonating my primary user account so perhaps by turning impersonation off I can get IIS_USER to be the only one who needs permissions for the temp folder.

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.