ftp_chmod inclusion?
Permalink
Over the past few days I've seen a few examples of where permissions have not been set correctly, in one instance the server was hacked. No way to tell if it was hacked due to the permissions being wrong or some other means at this point. This CMS like any other is going to be used by people who aren't familiar with things like file/directory permissions they are going to assume their hosts are going to make everything work exactly as it should.
Honestly number 3 here http://www.concrete5.org/documentation/installation/file-directory-... scares me. I can think of a number of FTP Clients that allow for changing the permissions, is it something hosts are doing to restrict it?
What about including ftp_chmod http://us2.php.net/ftp_chmod under "sitewide settings"? Some kind of toggle so they can turn it on and off or maybe password protect it to match their ftp password to make it more secure. Would it even work? I don't know, I'm not familiar enough with C5 yet to determine that. What I do know is most hosts will never say "your server was hacked because we didn't secure it, patch the apps on it, lock down the permissions correctly" etc, 99% of the time they will blame it on something the client is using, the other 1% they don't know what happened. It would really suck to see a great CMS like this get labelled as being insecure due to shoddy hosting.
Honestly number 3 here http://www.concrete5.org/documentation/installation/file-directory-... scares me. I can think of a number of FTP Clients that allow for changing the permissions, is it something hosts are doing to restrict it?
What about including ftp_chmod http://us2.php.net/ftp_chmod under "sitewide settings"? Some kind of toggle so they can turn it on and off or maybe password protect it to match their ftp password to make it more secure. Would it even work? I don't know, I'm not familiar enough with C5 yet to determine that. What I do know is most hosts will never say "your server was hacked because we didn't secure it, patch the apps on it, lock down the permissions correctly" etc, 99% of the time they will blame it on something the client is using, the other 1% they don't know what happened. It would really suck to see a great CMS like this get labelled as being insecure due to shoddy hosting.
There are lots of ways to secure a site, I'm thinking about the people who think Python is a snake and Apache is a Native American tribe. There are 1000s of people publishing everyday on the net which don't have the faintest clue about how it happens, or where their data is stored. They are happy their site is there, and if it were to get hacked they become completely bewildered because everyone involved in the process starts talking about things they don't understand. The purpose of a CMS is not just to manage content, but to make it easy to publish the content.
What about including the file permission setting as part of the installation process? If the permission setting were to fail, the installation doesn't have to stop, it just needs to print an error msg stating "file permissions ____ were not able to be set because _____. This poses a security threat, please copy this error and give it to your host". Give the user something to take to their host, or IT guy or whomever and say what does this mean and how do I fix it.
I'm pretty sure if most decent hosts were given an error msg like that they would either go sort it out so the user could set the permissions, or they would do it themselves. There are always exceptions to the rule.
What about including the file permission setting as part of the installation process? If the permission setting were to fail, the installation doesn't have to stop, it just needs to print an error msg stating "file permissions ____ were not able to be set because _____. This poses a security threat, please copy this error and give it to your host". Give the user something to take to their host, or IT guy or whomever and say what does this mean and how do I fix it.
I'm pretty sure if most decent hosts were given an error msg like that they would either go sort it out so the user could set the permissions, or they would do it themselves. There are always exceptions to the rule.
To solve all these problems with permissions I decided to use suPHP or apache2-mpm-itk. These allowed me run the php apps under my user/group account. Then I don't have to set it to 777 for the /files directory. Which becomes a security risk.
I think before you decide to do business with any hosting company you should ask if they offer any of these solutions suphp, apache2-mpm-itk, php fcgid or suexec to run your php apps.
Otherwise you'll either have to lessen the security for some files to make it work.