The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
Because drush is usually running drupal directly important checks on files modification possibilities get no or often wrong results.
This is also related to #2569495: There should be a new test for ownership of files and directories.
Steps to reproduce
For example create a folder "test" in webroot and make is writable by the cli user itself and the webserver. The GUI webserver check detects it correctly but not drush.
Proposed resolution
The minimum we need is to know which system user e.g. it's posix uid is running the related webserver/php process. This can be provided by setting.local.php. Easier to use would be an own protected route only to be called via cli which just returns this uid and guid information. With this information we can do fast tests. Maybe easier to code but with the limitations of the webserver would be an option to run checks through a route.
Comments
Comment #2
c-logemannCurrently setServerData() is just returning null on cli usage (see also #3451581: Get server uid function return unexpected type null. This is avoids corrects tests but even if we just open it would get wrong values of the file owner and they would be stored in state api.
Even if the current code will not mess up with the state API storage and cli can get correct serverdata.- This only would be available after a successful check via GUI. Beside the basic auth problematic (see related issue) this cann not work on a fresh test system e.g. in CI-Workflow.
Comment #3
c-logemannsetServerData() is currently triggered via cron. This could be an interface to run cron via http request. But in CI situations cron isn't always wanted depending on the system needs.
Comment #4
smustgrave commentedHello @c-logemann since it's been a few months wonder if you want me to un-assign?
Comment #5
c-logemann@smustgrave Sorry I was to busy in last time.I think we need an own route that can be triggered by drush also with basic auth credentials, see #3454933: Checks using sub requests with guzzle get wrong results on 403 situations
But please do not close the issue. When I find some time in winter I try to solve if nobody else steps in.
Comment #6
smustgrave commentedwanted to follow up again on this one.
Comment #7
c-logemann@smustgrave Thanks for bringing this issue up in my issue list. Maybe too early to assign yet again but in next weeks I may find the time to move on with this.
Comment #8
smustgrave commentedRock on.
Comment #9
smustgrave commentedIf https://www.drupal.org/project/security_review/issues/2569495 lands will this be ultimately fixed.