| 6:02 pm on Oct 26, 2012 (gmt 0)|
|I'm not sure what the change does. |
In Unix-like operating systems, /dev/null or the null device is a special file that discards all data written to it (but reports that the write operation succeeded) and provides no data to any process that reads from it (yielding EOF immediately).
|Could the file change itself. |
I'm not sure about PHP, but in most cases with the right permissions on a file it can be modified by anyone/anything.
| 6:10 pm on Oct 26, 2012 (gmt 0)|
Assuming I can change the permissions in cPanel. I put the old php.ini file back in. Changed my password. What permissions do most webmasters put on their php.ini files?
| 6:18 pm on Oct 26, 2012 (gmt 0)|
File permissions are 644. Assuming that is standard.
| 6:27 pm on Oct 26, 2012 (gmt 0)|
I think 644 means that files are readable and writable by the owner of the file and readable by everyone else. It would help to know which user owns the file and which one is modifying php.ini.
| 12:15 am on Oct 27, 2012 (gmt 0)|
The php.ini file was on the server when I moved my files to the new host about a year ago. So assume it is a standard php.ini file that comes with a hosted server. I never touch it, so when I saw that it had been changed I checked it to see what was different. But don't know how to find out who was modifying it. I am the only one modifying files, so when one changes that I didn't touch, I know something is wrong. I assume someone else has to have access to the server to change a file. Although my host seemed to think a script could change it. But I am not running any scripts. I use oscommerce for my cart, but my developer said that should not alter the php.ini file by itself.
Why would someone want to make it so the error log would not record errors.
I guess what I am trying to say is I am the only user, and it wasn't me.
| 12:51 am on Oct 27, 2012 (gmt 0)|
|Although my host seemed to think a script could change it. |
A script could change it depending on who the owner of that script is, but I'm not aware of osCommerce doing that.
|Why would someone want to make it so the error log would not record errors. |
One possible reason is so you wouldn't be aware that your files are being tampered with.
|I guess what I am trying to say is I am the only user, and it wasn't me. |
It's usually at this point that I recommend an audit to be sure your files haven't been tampered with. So long as you trust your developer he/she would probably be the one to ask about this.
| 5:51 am on Oct 27, 2012 (gmt 0)|
you should also check your client system for malware such as keyloggers or any vulnerability that may expose your passwords, for example.
| 6:06 pm on Oct 27, 2012 (gmt 0)|
This is kind of interesting. I had my host send me the error log for the last two days. You would think that there would be a gap from when it was turned off to when I turned it back on, but there is no gap. It was still logging errors. Also, my access log shows all the errors anyway. Does that mean the instructions in the php.ini file were not working?
| 5:50 am on Oct 28, 2012 (gmt 0)|
it depends on how you are running PHP but it is quite likely in your case the php.ini is only parsed on server startup vs on each request.
| 2:32 am on Nov 1, 2012 (gmt 0)|
I strongly suspect your webhost did it. Log files, especially those which are growing fast, are often problematic for hosts without adequate storage and log rotation systems. Quietly redirecting them to /dev/null does away with the need for rotating or storing them.
You should be able to check the last modified date on the file and confirm if it is the same date that you installed osCommerce.