Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#56189 closed defect (bug) (duplicate)

Updater tries to access File(/.svn) and /.git /.gh /.bzr

Reported by: robin-labadie's profile Robin Labadie Owned by:
Milestone: Priority: normal
Severity: minor Version: 3.7
Component: Upgrade/Install Keywords:
Focuses: Cc:

Description

Hi,

This line:
wp-admin/includes/class-wp-automatic-updater.php:104
Is trigerred when visiting the Updates page.

Using plugin "Query Monitor", we can see that it triggers errors as it tries to access ".svn" as well as .git, .gh and .bzr in rootdir of wordpress install as well as every single parent dir.

This leads to unwanted open_basedir errors:

is_dir(): open_basedir restriction in effect. File(/var/www/vhosts/terageek.org/.svn) is not within the allowed path(s): (/var/www/vhosts/terageek.org/shop.terageek.org/:/tmp/)
is_dir(): open_basedir restriction in effect. File(/var/www/vhosts/.svn) is not within the allowed path(s): (/var/www/vhosts/terageek.org/shop.terageek.org/:/tmp/)
is_dir(): open_basedir restriction in effect. File(/var/www/.svn) is not within the allowed path(s): (/var/www/vhosts/terageek.org/shop.terageek.org/:/tmp/)
is_dir(): open_basedir restriction in effect. File(/var/.svn) is not within the allowed path(s): (/var/www/vhosts/terageek.org/shop.terageek.org/:/tmp/)
is_dir(): open_basedir restriction in effect. File(/.svn) is not within the allowed path(s): (/var/www/vhosts/terageek.org/shop.terageek.org/:/tmp/)

Same errors occur with .git .gh .bzr with the exact same variation as the location it tries to access it, like:

is_dir(): open_basedir restriction in effect. File(/.bzr) is not within the allowed path(s): (/var/www/vhosts/terageek.org/shop.terageek.org/:/tmp/)

This is at least reproduced using PHP 8.1 on any WordPress hosted on a Plesk server (Debian and CentOS) that I've ever tried.

I'm unsure why WordPress would want to access these directories. A fix would be awesome.
I remain available if someone needs a test hosting to reproduce the issue.

Change History (5)

#1 @pbiron
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

@robin-labadie welcome to trac!

I'm unsure why WordPress would want to access these directories.

The reason the automatic updater is checking those dirs is to try to detect whether a site is under version control. If the site is under version control, then the automatic updater will not update it (under the assumption that the site owner will update it thru their version control system as needed).

open_basedir is a directive in the php.ini file, see the PHP manual for more info about it.

If that is a directive that you have not specifically set/changed yourself, then it is probably best to contact you hosting company for advice on how to correct this problem. Feel free to mention this ticket when you contact your hosting company.

Since this is not a problem with WP core, I'm closing this ticket.

#2 @Robin Labadie
2 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

Hello @pbiron
Thank you for your welcoming and attention.

I am the hosting company. (lol?)
I know how open_basedir works.

But in order for this script to not trigger errors, one would need to have the website having access to "/" on the server with open_basedir, which doesn't make any sense: you won't let a website own the whole system, especially on shared hostings. WordPress shouldn't ever have access to a file like "File(/.svn)". Maybe "../.svn" at best, but it won't ever have access to the filesystem base on the system.

Isn't there a cleaner way to implement this feature, than randomly checking paths and triggering a whole bunch open_basedir errors, in order to check if the website is under version control?

Thank you

#3 @hellofromTonya
2 years ago

  • Keywords needs-patch needs-testing removed
  • Milestone set to Awaiting Review
  • Version changed from 6.0 to 3.7

Updating the version to 3.7, as this code was introduced then by #22704 and changesets:

Also updating the ticket's status and keywords. Will leave to the Component maintainers to review Awaiting Review and whether to consider or reclose.

I'm unsure why WordPress would want to access these directories.

See #22704 for full discussions and context for why this was added into Core.

#4 @SergeyBiryukov
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from reopened to closed

Hi there, welcome to WordPress Trac!

Thanks for the report, we're already tracking this issue in #42619.

#5 @Robin Labadie
2 years ago

Thank you very much @pbiron , @hellofromTonya and @SergeyBiryukov for your welcoming and for following up with very precise and valuable info!

Hopefully issue 42619 will come to a solution.

Quality support like that will probably lead me to really learn PHP and help with the code at some point. That would be an honor to contribute to such a great project with great people.

All the best to you all contributors, keep up with the good work, and see you around!

Note: See TracTickets for help on using tickets.