Self-update detection fails on shared hosting configuration

[aydun]

Description of the bug

On some shared hosting (specifically civihosting.com), the file ownership and permissions do allow updates but the self-update detection does not recognise this leading to a screen requiring FTP details.

See #6742 and https://backdrop.zulipchat.com/#narrow/channel/218635-Backdrop/topic/Core.20update.20-.20needs.20ftp.3F

Steps To Reproduce

CiviHosting configuration is:

  drwxr-x--- root mygroup (home dir)
    drwxr-xr-t root mygroup www
      drwxrwxr-x root mygroup www
      drwxrwxr-x root mygroup subdomain1

The directories under $HOME/www are managed as part of the subdomain management via the control panel.

The default configuration directory is $HOME/www/www owned by root, writable by the webuser group.

The self-updater examines the ownership of the configuration directory and therefore fails in this configuration, resulting in a FTP screen.

Actual behavior

FTP cred screen

Expected behavior

Installation should continue.

Additional information

Add any other information that could help, such as:

• Backdrop CMS version: 1.29.1

[quicksketch]

Hi @aydun, welcome to the Backdrop community! Thank you for filing this issue and the associated PR! The code looks good to me; solid conceptual improvement. settings.php is indeed much more likely to match the file ownership because it's typically written by the web-server during installation of Backdrop.

In the Drupal-sphere (where this code originated), the conf_path() was usually a nested directory (like sites/default), but in Backdrop it's usually the root directory. I wouldn't have expected a difference in ownership, but I think your example proves otherwise!

This could use a second set of eyes to verify, but this seems ready to me (minor code-comment issue aside, I left a note on the PR).

[aydun]

Thanks @quicksketch

[izmeez]

Our problem may be different. Nonetheless, the PR was tried as a patch and even though it applies without problems it does not solve our case.

The server configuration permits new modules to be installed through the UI without difficulty. However, updating modules or core fail with the message:

Your server does not support updating modules, themes, and layouts from this interface. Instead, update modules, themes, and layouts by uploading the new versions directly to the server, as described in the handbook.

This seems odd and it's not clear why this is happening.

[quicksketch]

@izmeez Are you also on civihosting.com?

The permissions check is not comprehensive. It's only checking the permissions of a single directory (or now a file, after the current PR backdrop/backdrop#4909). On most sites, the ownership of all PHP files is the same, but a single file being the wrong permission may prevent an automatic update from being successful. Do you have permission to a terminal/console/ssh on your host? You might be able to fix the problem by following the documentation on setting looser permissions.

[izmeez]

@quicksketch Our issue is on Drupal Forge / devpanel.

What struck me is there are 2 distinctly different paths that lead to problems:

1. Installing new modules and themes. If this fails it tends to invoke authorize.php and displays that you need FTP access which is a no go. This is similar to issues with Drupal 7.
2. The second is updating existing modules and also core. This invokes the message, Your server does not support updating ....

I'll take a look at the looser permissions docs. Thanks.

[izmeez]

@quicksketch The looser permissions as described in the docs works for our use case. Thanks.

[izmeez]

Ok, reading through the PR changes again, I see it as being a sensible change that may help resolve some cases. I have added the patch anyway and so far have not observed any untoward effects.

[quicksketch]

Thanks @izmeez for confirming. I merged backdrop/backdrop#4909 into 1.x and 1.29.x, this will be in 1.29.3. Thank you @aydun pointing out the problem and providing a fix!

[aydun]

Thanks for merging @quicksketch

[izmeez]

This issue is still haunting me. I'm not an expert with DevOps and maybe it's a carry over from Drupal 7 and not applicable to Backdrop. With Drupal 7, after it is installed and when it runs it protects the settings.php file by changing the permissions to 444. This would make it an unsuitable file for checking if it is writable. Maybe, Backdrop is not fully protecting the settings.php file as Drupal 7, or maybe this is not the best substitute check?

[izmeez]

I have opened a new issue to elaborate on our problems, #6765