its states that www owns the file and I can't edit it any more.
I guess you used the install script.
So did I...
I had to ask the hosting company to change permissions on the file.
So did I...
I had to ask the hosting company to change permissions on the file.
I suspect this is because the config was written in the webserver's own thread.
This is the typical result of executing filesystem changes by calling a webpage like an install page (since the webserver actually does the filesystem changes).
Ideally, such a script should be modified to enable the domain administrator to read and write the file on a shared server (possibly where the group is effectively the users of the domain with shell access, and www is a member of the group).
The upside is that you can execute changes with webserver permissions by using the same trick. There is an interesting tool called Myshell
http://www.digitart.com.mx/php/myshell/
which essentially allows you to run an interactive shell through a web browser which has the same permissions as the webserver. This should allow you to reverse any unwanted changes, remove config.php, or change permissions so that you can do what you want to the config file.
This assumes that you have php running with sufficient functions and permissions.
The responsibility for the consequences of using this tool are up to you, but it might be handy. Worth removing myshell afterwards, to ensure you don't leave any unnecessary security holes.
Cefn
http://cefn.com
This is the typical result of executing filesystem changes by calling a webpage like an install page (since the webserver actually does the filesystem changes).
Ideally, such a script should be modified to enable the domain administrator to read and write the file on a shared server (possibly where the group is effectively the users of the domain with shell access, and www is a member of the group).
The upside is that you can execute changes with webserver permissions by using the same trick. There is an interesting tool called Myshell
http://www.digitart.com.mx/php/myshell/
which essentially allows you to run an interactive shell through a web browser which has the same permissions as the webserver. This should allow you to reverse any unwanted changes, remove config.php, or change permissions so that you can do what you want to the config file.
This assumes that you have php running with sufficient functions and permissions.
The responsibility for the consequences of using this tool are up to you, but it might be handy. Worth removing myshell afterwards, to ensure you don't leave any unnecessary security holes.
Cefn
http://cefn.com
Cefn writes:
There is an interesting tool called Myshell: http://www.digitart.com.mx/php/myshell/
Anybody know how to download this software? The download link at digitart.com is not working for me:
http://www.digitart.com.mx/php/myshell/download.html
Some googling I did found no other download sources.
-Matt
There is an interesting tool called Myshell: http://www.digitart.com.mx/php/myshell/
Anybody know how to download this software? The download link at digitart.com is not working for me:
http://www.digitart.com.mx/php/myshell/download.html
Some googling I did found no other download sources.
-Matt
Well, here is a version of myshell which I retrieved and slightly modified for my use a while ago (username and password and warning e-mail address changed to protect the innocent).
You will need to add your own username and password and warning e-mail address to make this moderately secure.
To make it more secure change the name of the php script from myshell.php - the default - owing to this sort of security issue if you link to it, or mistakenly allow indexing on the directory it's in... http://www.theregister.co.uk/2001/11/28/the_google_attack_engine/
If you are using Apache, add a .htaccess permissions file to prevent access to the chosen php page, with a secure username and password (in addition to the myshell.php username and password) and to prevent indexing of the directory which contains it. Call me paranoid.
Information about .htaccess files are here...
http://httpd.apache.org/docs/howto/htaccess.html
However, to make it most secure, don't leave it up there on your website at all. Your web server admins will be grateful.
You might also wish to consider phpshell (see http://www.gimpster.com/wiki/PhpShell) which is what myshell was originally based on.
None of this will work if your web hosting provider forces php to run in safe mode, but then, neither will the install script so you're probably OK there.
Cefn
http://cefn.com
You will need to add your own username and password and warning e-mail address to make this moderately secure.
To make it more secure change the name of the php script from myshell.php - the default - owing to this sort of security issue if you link to it, or mistakenly allow indexing on the directory it's in... http://www.theregister.co.uk/2001/11/28/the_google_attack_engine/
If you are using Apache, add a .htaccess permissions file to prevent access to the chosen php page, with a secure username and password (in addition to the myshell.php username and password) and to prevent indexing of the directory which contains it. Call me paranoid.
Information about .htaccess files are here...
http://httpd.apache.org/docs/howto/htaccess.html
However, to make it most secure, don't leave it up there on your website at all. Your web server admins will be grateful.
You might also wish to consider phpshell (see http://www.gimpster.com/wiki/PhpShell) which is what myshell was originally based on.
None of this will work if your web hosting provider forces php to run in safe mode, but then, neither will the install script so you're probably OK there.
Cefn
http://cefn.com
About the file permissions, it's difficult for the install.php script to know who to allow write access to. It could easily open up a hole that allows others to change your settings or insert bad PHP code.
So we decided it was better to err on the side of being too secure.
One can always use FTP to delete the config.php file and recreate it.
So we decided it was better to err on the side of being too secure.
One can always use FTP to delete the config.php file and recreate it.
Martin,
Tell me if I'm wrong, but I'm not sure that most users on a shared host can delete the file using ftp. Strictly, only www can edit the file I think, and the ftp daemon will only be able to write files which it (or you as a user) have permission to modify. I don't have exhaustive experience of lots of different shared hosting arrangements, though and they're probably all a bit different.
You're quite right to err on the side of security. Unfortunately creating files through the web interface can be a one way street for those on shared hosts, unless they can escalate their privileges via legitimate, or slightly dodgy means like myshell or phpshell. Please put me right if I have misunderstood somewhere.
There may be no easy way to fix this within the install script, although I think the group membership approach might be worth looking at - to do it moderately securely you would have to activate this specifically when installing, and specify the group.
Alternatively you could perhaps provide support for the files written by the install script to be removed through some admin-password-protected operation in a moodle config page (which would then execute as www).
Moving config.php will kill the moodle install until it is replaced, but it won't leave valid moodle site admins with this catch22 on permissions. Alternatively a similar password-protected operation to make config.php file-permissions more permissive might be an option.
Cefn
http://cefn.com
Tell me if I'm wrong, but I'm not sure that most users on a shared host can delete the file using ftp. Strictly, only www can edit the file I think, and the ftp daemon will only be able to write files which it (or you as a user) have permission to modify. I don't have exhaustive experience of lots of different shared hosting arrangements, though and they're probably all a bit different.
You're quite right to err on the side of security. Unfortunately creating files through the web interface can be a one way street for those on shared hosts, unless they can escalate their privileges via legitimate, or slightly dodgy means like myshell or phpshell. Please put me right if I have misunderstood somewhere.
There may be no easy way to fix this within the install script, although I think the group membership approach might be worth looking at - to do it moderately securely you would have to activate this specifically when installing, and specify the group.
Alternatively you could perhaps provide support for the files written by the install script to be removed through some admin-password-protected operation in a moodle config page (which would then execute as www).
Moving config.php will kill the moodle install until it is replaced, but it won't leave valid moodle site admins with this catch22 on permissions. Alternatively a similar password-protected operation to make config.php file-permissions more permissive might be an option.
Cefn
http://cefn.com