There is a patch to work with ACL's that is currently working it's way slowly into core. This module is also susceptible to the ACL issue since it relies on the is_writable() function.
To reproduce the issue you need a web server that runs as a different user than the owner of the site files.
chown -R USER:USER sites/default/files
setfacl -Rm d:u:APACHE-USER:rwx,u:APACHE-USER:rwx files
Apply the patch from #944582: Check for execute permissions on directories that require file write permissions and go to the status page (/admin/reports/status) or attempt to run update.php - you will see the following error:
GOOGLE TAG MANAGER SNIPPET DIRECTORY
Not writable
The directory sites/default/files/google_tag is not writable. An automated attempt to make the directory writable failed, possibly due to a permissions problem. Make the directory writable.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | google_tag_acl_fix-8.x-1.x-dev-2959218-4.patch | 1.78 KB | slydevil |
| #4 | google_tag_acl_fix-8.x-1.0-2959218-4.patch | 1.44 KB | slydevil |
Comments
Comment #2
slydevil commentedComment #3
slydevil commentedComment #4
slydevil commentedComment #5
solotandem commentedThe core issue you linked to is adding the is_executable check. The proposed patches to core are guaranteed to fail on a remote stream wrapper as they fall back to calling is_executable($uri). The failure is due to a "bug" in PHP whereby it returns FALSE automatically because the stream is not the "local files" stream and the uri points to a directory.
Regarding is_executable(), I submitted a pull request to PHP that has been committed. It fixes the real problem with the inconsistent results for stream=local (all but the ACL part) and provides a valid result for all other stream wrappers.
All this workaround by core should not be necessary if PHP actually implemented its stream wrapper interface. The register function includes an "is local" parameter that could be used by PHP during these file system access checks. But PHP stream wrapper interface does not provide a routine to return the "local path" on such a wrapper (similar to the realPath routine in Drupal). If it did then PHP could call the access routine (that respects the ACLs) on all local streams and provide the correct result.
Regarding the patch, it refers to a function that does not yet exist in core (and may not be present in the release used by someone else). It essentially makes a dependency on core 8.6.N+ for this project. Do we need to copy core routine to this project and wrap it in function_exists()?
Comment #7
solotandem commentedThanks for adding this request.