Make a file writable on the web server
Permalink
We've developed a website for a client who has asked for their preferred server supplier to host. All fine by us. But when we want to make updates to the website we get messages like the one attached. As a result we have asked to make a file writeable.
This is the response we have got ...
The request to make a file writable on the web server - I have updated this particular file for now, so any attempt to re-run it should work. However this is absolutely against best practice to have writeable files within the document root. This is not just a XXXXXXX policy but part of OWASP (one of the largest providers of web security advice -https://en.wikipedia.org/wiki/OWASP)... guidance -https://www.owasp.org/index.php/File_System... I’ve discussed this with our IT Director and explained that I’ve done it for now, but a better method has to be found.
Is he right? My only concern is that not making the file writable renders the CMS redundant.
Does this learned community have any thoughts? Or even what the better method could be.
Thank you.
Mark
This is the response we have got ...
The request to make a file writable on the web server - I have updated this particular file for now, so any attempt to re-run it should work. However this is absolutely against best practice to have writeable files within the document root. This is not just a XXXXXXX policy but part of OWASP (one of the largest providers of web security advice -https://en.wikipedia.org/wiki/OWASP)... guidance -https://www.owasp.org/index.php/File_System... I’ve discussed this with our IT Director and explained that I’ve done it for now, but a better method has to be found.
Is he right? My only concern is that not making the file writable renders the CMS redundant.
Does this learned community have any thoughts? Or even what the better method could be.
Thank you.
Mark
I might be wrong and we might have a different understanding of what the "root" is. But it seems to me that file, or anything in the application folder for that matter, is not at the root.
Concrete5 needs to have write authorization in the applications folder as it is used to store:
- file manager files
- cached files
- auto-generated doctrine entities
- core config values
- packages config values
- backups of packages that are being updated
And probably other things I am forgetting.
You'll have a hard time making it work if the applications folder is not writable.
But again, I really don't think this qualifies as the "root"
Concrete5 needs to have write authorization in the applications folder as it is used to store:
- file manager files
- cached files
- auto-generated doctrine entities
- core config values
- packages config values
- backups of packages that are being updated
And probably other things I am forgetting.
You'll have a hard time making it work if the applications folder is not writable.
But again, I really don't think this qualifies as the "root"
The reason why you may have ended up with files not writable could be that the FTP user and web server Apache user are not the same, or not in the same group.
As well as checking permissions, also check file ownership and user group membership.
As well as checking permissions, also check file ownership and user group membership.
It is actually the server provider refusing to make the files writable as this is not best practice. Is that a fact?
Just to clarify:
When you run a Webserver process (Apache or nginx usually), this process runs as a user on your server. This user is normally the www-data user that belongs to the www-data group. It should not be possible to log on to the server as this user.
When you log into your server with an FTP connection, this is another user account, belonging to another user group. If you now change a permission of a file to be writable, this would most probably mean that it is writable for that FTP user OR in the worst of cases - for anyone else. This of course is neither what you need, nor what could be advised.
So most probably you can not make this change by FTP but only via ControlPanel or by requesting support.
Opening up a files write permissions to anybody but the webserver process is not advised and should not be done! So most clearly, you need to communicate to support what exactly you need - which would be writable for the webserver user.
Kind regards
When you run a Webserver process (Apache or nginx usually), this process runs as a user on your server. This user is normally the www-data user that belongs to the www-data group. It should not be possible to log on to the server as this user.
When you log into your server with an FTP connection, this is another user account, belonging to another user group. If you now change a permission of a file to be writable, this would most probably mean that it is writable for that FTP user OR in the worst of cases - for anyone else. This of course is neither what you need, nor what could be advised.
So most probably you can not make this change by FTP but only via ControlPanel or by requesting support.
Opening up a files write permissions to anybody but the webserver process is not advised and should not be done! So most clearly, you need to communicate to support what exactly you need - which would be writable for the webserver user.
Kind regards
Ultimately yes, having no writable files is more secure. Back in the days of static HTML sites this was probably a reasonable policy. Having no readable files is even more secure ;-)
In practice, any CMS depends on some files being writable by apache for file uploads, updates, package installation.... etc. The files should certainly not be writable globally (no 0777 permissions).
Requirements for file writability within the web space can be reduced by composer based installation of c5, where core files sit outside of the web root. But even then having some writable files within the web space cannot be avoided. Composer based installation also depends on having greater access to the server than some hosting accounts provide.
In practice, any CMS depends on some files being writable by apache for file uploads, updates, package installation.... etc. The files should certainly not be writable globally (no 0777 permissions).
Requirements for file writability within the web space can be reduced by composer based installation of c5, where core files sit outside of the web root. But even then having some writable files within the web space cannot be avoided. Composer based installation also depends on having greater access to the server than some hosting accounts provide.
It should not be accessible from outside or any other user by the webserver user (usually www-data), which should not be possible to log in as.