Review updated Securing file permissions and ownership

Hi,

I thinks this page needs an overall rewrite, it should be shorter, give less background and be more directive
Chapters "Configuration examples", "Quick lesson in permission's numeric equivalents" & "Addendum on chmod Non-Numeric Permission Notation" should be merge and shorten, only pointing to external documentations about Linux permissions.

The sysadmin part should mention about the "deploy user" roles, it should be allowed to modify all files in order to release the application (replace old code with the new version, update settings.php, keep contributed files, ...).

An example of a fix permission script should be provided, it should be able to find its configuration by scanning the settings.php, looking for:
file_chmod_directory, file_chmod_file, file_public_path, file_private_path and file_temp_path parameters

I agree on most parts of#12 but the part about scanning parameters.

IMHO, that will make the script complex and I think it would be more fragile, unless is Drush based, so it pulls conf from Drupal itself. But that implies a dependency with PHP, Drush and Drupal, it will fail if permissions prevent Drupal from bootstrapping.

I use a script for this and by default detects files and private under sites folder as content folders, but you can add parameter to declare other folders. Since sites folder structure don't change often I think it is ok if users are required to do a minimal setup in the shake if simplicity.

As a reference here's is the script: https://github.com/Metadrop/drupal-fix-permissions-script (I just published it)

Thanks for the comments. Great that you wrote a script @tunic, feel free to add a link to it in https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... → .

@O'Briat: Those are great suggestions. If you have time at some point, it would valuable for the community if you shortened the page, where you think it's relevant.

@ressa I'll try to do it soon.

@tunic: I didn't mean to bootstrap drupal in order to extract variables (I'm well aware about the impact of faulty Drupal installation on such scripts, specially during deployment), I rather had in mind to parse the settings.php file in an (optional) auto detect mode.

I wonder if a third username is not missing: the one that run drush (or cron), does it need to be run via sudo -u webuser or just be the same as the deploy user ?

#15 About the script, I think that's a great functionality, but for a demo or base script could too much effort. At least, I would add simple script on the doc page and later, if possible, add the auto discovery functionality.

About the third user, I guess it depends on the setup, but a typical option is to run cron jobs with the web server user. In that case, probably run by root but using sudo because those users tend to be disabled and cron doesn't run for disabled users. But I wouldn't add a third user to the docs because it will be too complex. Maybe mention what i say here, that if web server user is disabled you need to use sudo.

As suggested by #14 I've added a link to the script to fix permissions of #13 int he linked page ( https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... → ).

Since we agreed in the discussion page → that it is Drupal 10 ready, I am changing status. Thanks everyone for working on this!

Automatically closed - issue fixed for 2 weeks with no activity.