File permissions issues with AbstractDrupalCommands::permissionsSetup()

[vever001]

Hi,

Is there a valid reason why AbstractDrupalCommands::permissionsSetup() makes a chmod 775 -R on the whole sites subdir here?

We currently have code under the sites subdir (D8 multisite - e.g: sites/*/modules, sites/*/themes) where all files are 664.
Every time permissionsSetup() gets called, these files get their permissions changed.

If I'm not mistaken, it should only make a chmod 775 on the sites-subdir (non-recursively) and alter the permissions for settings.php.
Could you confirm? If so I can work on a PR.

Thank you,
Hervé

[donquixote]

Hello,
the correct thing to do here would be to enable the "x" bit on directories, but disable it on files.
On directories, "x" means you can get a list of the directory contents. For most directories this is desirable.
On files, "x" means you can execute the file. For most files this is not desirable.

With pure cli commands this can be achieved by:

chmod -R a-x,a+X dir

The lowercase x applies to all files and directories, the uppercase X only applies to directories.
(See https://superuser.com/a/91966, but you have to go into the comments to find the ideal solution.)

Unfortunately I don't see how we would do this with symfony filesystem recursive chmod, which expects an integer umask and does not work with strings like a-x.

[donquixote]

I also notice that the recursive chmod of symfony filesystem also modifies symlinked files.

I have a project with a symlink from build/sites/default/setings.symlink.php to ../../../resources/settings.symlink.php. Every time I run composer install, the drupal:settings-setup changes the perms for the target file (not the symlink itself) to 775.

[donquixote]

Also why do we make settings.php and other files writable?