Securing file permissions on any web server is a process that differs from user to user. If the Security Review module discovers that it can write to files and directories on the webserver, it recommends one single uniform process to resolve the issue and further links to the documentation on d.o → regarding how to fix this, which also makes the same error.
In my case (and likely the case of some others out there), my site is hosted in a SHARED hosting environment. My Apache user is my account username, and my "group" also has the same name. That group only has one user: myself. I am not a member of any other group and therefore, I cannot change the group or owner of ANY of the files which I have uploaded - not even to the group "nobody". I am stuck with all file and directory ownership settings of (myaccount):(myaccount). In my case, the only way to resolve this issue is to remove "Write" permissions from myself on all directories and files, effectively making my entire code base read-only until I want to make updates or changes. While a pain, this is absolutely worth doing to prevent my site from being hijacked.
The problem here isn't so much the solution I eventually found. The problem here is that all the documentation in this module and d.o assumes that Drupal users are administering their own servers. Finding the proper solution for my situation should not have been this difficult at all - and moreover, this module made it more difficult to resolve this problem by providing a solution which is not universally appropriate for all servers site-users. I mean, I suppose it's possible that I am the only user out there serving a Drupal site from a shared hosting provider - but I find it hard to believe this would be the case. Simply run a search on d.o, stackexchange, or Google on "file permissions" and you will find a TON of user questions and even more answers/solutions.
I suppose this issue raises a bigger question: Has Drupal ever decided who its own target audience is? Is Drupal designed to be used by end users or developers? Depending on the answer to that question, this issue might be moot. However one would think developers would not even need such a tool as the Security Review module in the first place. The people who install/use the Security Review module are the ones who need the most help in this area, and therefore, its documentation and proposed interventions should be targeted toward site-builders, end-users, and novices.
Modify the instructions in the module, readme.txt, and even on d.o to state what the outcome should eventually look like, rather than the steps you should take to get there. This issue also effects the 7.x branch of the module.
This will help set users out on the path to their own unique solution without unnecessary detours.
1)Maintainer Review, decision on what, if anything to change
2)Everything that is decided upon.
Please note that I am willing to help as time allows. I am not a developer but I can contribute to/write documentation, etc.
In security-review/help-security-review/file_perms, modify the phrase: "In most cases you can fix this by simply altering the file permissions or ownership. If you have command-line access to your host try running "chmod 644 [file path]" where [file path] is one of the following paths (relative to your webroot). For more information consult the Drupal.org handbooks on file permissions." Well, in my case, I had already done this but this does not solve the problem. I cannot change the file owners to another user, I cannot create new users, I cannot reassign groups. Even worse, all the documentation at the link provided is written for developers and server administrators and is full of solutions which require root access - there is no documentation available on potential solutions for users of shared hosting providers.
Proposed new phraseology: "The way to fix this problem will be different depending on your individual server setup. If you are a server administrator with root access, see the Drupal.org handbook on file permissions. If you have shared hosting, your options will be severely limited and you should check directly with your hosting provider. Whatever the method, the end result should be such that the web server itself cannot write to any of the Drupal core directories or individual files."
Probably none, but needs expert review
Probably none, but needs expert review
Fixed
3.0
User interface
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Added "If you have shared hosting, your options will be severely limited and you should check directly with your hosting provider. Whatever the method, the end result should be such that the web server itself cannot write to any of the Drupal core directories or individual files" to the help text in the 3.0.x. branch
Automatically closed - issue fixed for 2 weeks with no activity.