Drush powered security check of file permission setting

The security review module does some of this already (though it doesn't change permissions, just check them).

http://drupal.org/project/security_review

Frankly, it's a hard thing to figure out because you need to know:

1. What user is the webserver running as?
2. What user(s)/group need to be able to login via SSH/SFTP/NFS/whatever and edit the files
3. What groups might the webserver be in?

I'm skeptical that an automated solution can work for changing the permissions, though I think it can at least help with identifying insecure permissions.

An alternate approach would be to just have drush security-file-review be a wrapper around the checks that are in the Security Review module. We've been talking about that internally as a good idea, but haven't done anything about it yet.

There's also http://drupal.org/project/hacked which does the md5 thing, though it is within the root and therefore somewhat suspect as you say.

Just for the record (it's a side issue here, but worth mentioning) we specifically reviewed all of these modules before building security_review (see Ben's list of contrib for securing your site) and there is no overlap that we've built in terms of features. There is overlap in terms of namespace, perhaps, but the other modules are all in weird states of halfway working or being "never use on a production site" mentality which we wanted to avoid.

I was thinking about this problem a while ago, and I proper approach is hard but could be done with some work (probably it would be too much for drush core).

Of course a simple find based approach would be easy, but it relies on users knowing the correct permissions for their hosting setup to start with (and let's be honest, how many times have you seen newbies chmod 777 on their vhost?) - and of course if you do know the right permissions is pretty trivial to do with a find -exec command, so I don't think a drush command adds much value.

Because of the huge range of different server setups determining the correct permissions can't be done completely from the command line - you will need a php proxy script that you access via http to check file/directory readability/writability from the web php. You would also need to make http requests to check Apache file/directory readability.

Essentially you have 3 actors to consider:
* Apache user
* PHP web user
* CLI user
Of course on many setups 2 (or even all!) of these actors may actually be the same user, or they may be separate users but share a group.

We have 5 cases of permissions:
* Script files - rw by CLU user, r by PHP user, no permissions for Apache (unless Apache user is also PHP user, of course)
* Resource files (module icons etc) - rw by CLU user, r by PHP user, r by Apache user
* Uploaded files - rw by CLI user, rw by PHP user, r by Apache user
* Normal directories - rwx by CLI user, rx by PHP user, r by Apache user
* Upload directories - rwx by CLI user, rwx by PHP user, r by Apache user
Of course, these are the theoretical optimal permissions, and are normally not attainable as 1 or more of the actors share a user or group.

Give the above, I think determining optimal permissions through reasoning logic is going to be way too hard - I was thinking perhaps an empirical approach might work, however.

In essence this could look something like this:
* Create sample target files and directories for each of the permission cases, by creating a file and directory as the CLI user (i.e. drush) and also as the PHP user (via the proxy).
* Determine users/groups we know about by examining these files/directories.
* Produce an array containing each possible user/group combination for each file/directory type (the upload directories/files would need to stick with the PHP user to allow deletes etc, but the group could vary).
1. Iterate through each file/directory type and user-group combination:
2. Chown all the files/directories to that user-group combination.
3. Start with 000 permissions, test for each user (using http requests for Apache and the php proxy)
4. Increment the permission until we find and record the lowest (i.e. least permissive) combination of user-group and permission that fulfils the permission criteria for that file/directory.

Eventually we should end up with a list of the ideal user, group and permission for each type of file and directory. We could then produce a settings array that the user could place in their drushrc that would instruct a "check permissions" and "fix permissions" command. It could also produce file_chmod_directory and file_chmod_file $conf lines they could place in their settings.php to ensure optimal permissions for uploaded files in Drupal 7.

Its pretty clear from the deep discussion here (keep going!) that this too much for drush core. feel free to put this integration into security review module. You can just instruct folks to move the drush command out of web root and into one of the several other places that drush looks for commands.

I agree this belongs to a third party module, especially since the code has already been written! :)

For the "webserver user" problem, people may want to look at how aegir does it, we have some code sitting somewhere to figure that out... It's the "web_group" option, iirc. You should find something if you grep for that.

How about if we split this up? This issue can deal with security policy checking, and in Drush core we can deal with actually setting the permissions.

I've already got something working over at #990812: Add a "permissions" subcommand to fix/set all file permissions for the Drush core portion, and the maintainers are in favour of it. So far, it only sets sane defaults, but it's a start.

this is a great idea. Would love to see even a rough:
drush security-file-review

For D6 & D7!

Did some random googling today and bumped into #990812: Add a "permissions" subcommand to fix/set all file permissions which lead here. Just want to suggest that whatever approach ends up becoming finalized that it considers sites where running commands like find would take days if they ever completed at all. An example would be a site running 6 terabytes of nfs mounted media in a files directory.

How would you propose this be tackled without running find or an equivalent? You could act on only code etc + the files in the files table, but that would potentially leave unassociated (e.g. legacy) files without correct permissions. Incidentally, if running find on a 6GB NFS mount is taking days to complete, you probably have some network/server problems (or you host a insane number of tiny files perhaps!) - as a benchmark, I can run "find" on my underpowered consumer level 3TB NFS mounted NAS with ~200k files and it only takes a few minutes to complete.

I think you do make a good point that it would be good to consider efficiency - so ideally we should only do a single scan through the files, not one for each change/assertion.

Just pointing out that those insane but optimized systems without network issues are not typical but they do exist ... and with any luck, Drupal will see more of them in the future. I ran find . -type d -exec echo {} \; against an old copy of our files directory on the same media mount as production. These are not slow machines and the command was run from a machine sitting on the same rack connecting through internal ip addresses... the live data is about 6 months more mature and more massive (site generates about 3500 nodes a day ... many of which are slideshows). This command took 2 hours and 26 minutes to complete. If we hit our projections I could see that easily tripling within the next year. Admittedly, this is not as extreme as my initial post as I had no metrics, but I think it bears consideration.

I'd suggest providing a way to break the processing up so that it can be queued and handled in chunks. If the process is interrupted it can resume without starting over. I would never launch any process against our environments that run this long without knowing that it can be stopped and properly resumed without causing undo stress on the machines. I would also be quite happy if there were a way to generate a report indicating the size of the impact before making changes.

Just a note that #990812: Add a "permissions" subcommand to fix/set all file permissions has been updated, and now includes a --audit option. This command falls short of handling all of the feature requests on this thread, but it does do quite a lot.

As Drupal6 has been EOL https://www.drupal.org/about/drupal6-eol closing as outdated

When it's not implemented in actual version this feature request isn't outdated.

Thanks for the feedback, @C-Logemann.

smustrave in #19 was closing as outdated the features that don't make sense in the current version of the module. I think if there's no progress for 10 years that's a pretty good indicator it won't move forward.

IMO this is outside the scope of this module. The permissions concept of the module is already one of the more controversial and hard to maintain features. Attempting to do that same feature via drush seems likely to cause more confusion and trouble.

If it's not outdated then it's won't fix for 8.x.

I think a drush check of file permissions is a good idea. But the concept of testing a special permission setup isn't really a "review" in my opinion. And because this idea depends on concrete hosting configurations it needs more than just activate one setup for all use cases. So I agree to not integrate this idea. Maybe this should solved be in a custom drush plugin or can live in a new contrib module where maybe somebody likes to integrate some configuration options and especially tools and documentation to help with concrete hosting situation.