Skip to main content
Topic: Another Package Manager Bug? (Read 3575 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Another Package Manager Bug?

This happen after package is uploaded and before we click install for the first time.

QuoteType of error: General
Warning: file_exists(): open_basedir restriction in effect. File(/var/www/clients/client2/web27/web/packages/QRR.elkarte.ahrasis.com.v.106.zip/package-info.xml) is not within the allowed path(s): (/var/www/clients/client2/web27/web:/var/www/clients/client2/web27/private:/var/www/clients/client2/web27/tmp:/var/www/localhost/web:/srv/www/localhost/web:/usr/share/php5:/usr/share/php:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin)
http://localhost/index.php?action=admin;area=packageservers;sa=upload2
File: /var/www/clients/client2/web27/web/sources/admin/PackageServers.controller.php
Line: 603
Last Edit: November 01, 2016, 12:36:17 pm by ahrasis

Re: Another Package Manager Bug?

Reply #1

I'm not sure I would call it a bug as such.
file_exists cannot be performed due to open_basedir.
I'd say first try to fix the webserver, otherwise the package manager would not work and you may have problems?
Bugs creator.
Features destroyer.
Template killer.

Re: Another Package Manager Bug?

Reply #2

Isn't open_basedir restriction is good for some security reasons or we should simply disable it because of this warning?

Re: Another Package Manager Bug?

Reply #3

You should probably set it properly.
TBH I'm not a server-guy, so I can't give you much more details, maybe if @Spuds passes by may have some suggestions (or revert what I said lol).
Bugs creator.
Features destroyer.
Template killer.

Re: Another Package Manager Bug?

Reply #4

I think it is already set properly but I posted in howtoforge to get some answers/feedbacks for it.

I noted that disabling it is quite easy but its security will be compromised:
Quote from: Till BrehmThe problem is misbehaviour in wordpress and not a wrong setting in ispconfig. If wordpress does not find its config file, it tries to traverse the path downwards and tries to find the file wp-config.php in other locations. So wordpress tries to open folders that it is not allowed too because they are outside of its web directory and this triggers the open_basedir.

You can disable open_baesdir of course by simply setting / as open_basdir path, but thst quite insecure as it allows all your website users to read the mysql passwords and other data of other websites.

Anyway, I find a solution suggested by karlbenson in SMF long time ago (2009) that is by changing file_exists to @file_exists in that line 603.

It works for me but I am not so sure for how long and whether that'll create another issue.

Re: Another Package Manager Bug?

Reply #5

I finally concluded that this is a bug as I compare the code with 1.0.9. The default code in 1.1 Beta 3 is:
Code: [Select]
(!($package->isDir()) && file_exists($package->getPathname() . '/package-info.xml')
Where, based on 1.0.9, it is supposed to be:
Code: [Select]
(!($package->isDir() && file_exists($package->getPathname() . '/package-info.xml'))
It is the containing bracket, I think, which is incorrectly placed. I did the above changes and the error that is shown after addon's upload is now properly gone, instead of only being suppressed and instead of disabling the open_basedir restriction.

I hope this can be confirmed, as I myself am not so sure whether this the right fix.

Re: Another Package Manager Bug?

Reply #6

Quote from: ahrasis – I think it is already set properly but I posted in howtoforge to get some answers/feedbacks for it.
I told you I'm not a server guy. :P

Quote from: ahrasis – I noted that disabling it is quite easy but its security will be compromised:
Just to repeat myself: I never said to disable it.

Quote from: ahrasis – Anyway, I find a solution suggested by karlbenson in SMF long time ago (2009) that is by changing file_exists to @file_exists in that line 603.
Not quite a "solution" but rather a workaround.

Quote from: ahrasis – I finally concluded that this is a bug as I compare the code with 1.0.9. The default code in 1.1 Beta 3 is:
That one, instead, looks like a proper solution. ;)
Bugs creator.
Features destroyer.
Template killer.


Re: Another Package Manager Bug?

Reply #8

Glad you figured it out :D ...  I was not sure why you were getting that error as the file appeared to be in the allowed open_basedir path.

IMO there is nothing wrong with using open_basedir, its something you should use if you have a multi user/site VPS, helps keep folks contained to where they (and scripts) can access.

Re: Another Package Manager Bug?

Reply #9

Quote from: emanuele – I applied the fix proposed and did a bit more because that pattern is used elsewhere as well:
https://github.com/elkarte/Elkarte/commit/bb76c47a5326026603dd7a673c5fb531d0b91bbf
Great. I have had a quick look but do not comprehend anything, yet. I am also not sure whether to test it since there is other file introduced.

By the way, from the quick look, is the backslash in this new PackagesFilterIterator class file proper because I haven't seen one like it before?
Code: [Select]
class PackagesFilterIterator extends \FilterIterator

Re: Another Package Manager Bug?

Reply #10

yeh it's proper/valid syntax, but not required because it's all in the same namespace - none.

Re: Another Package Manager Bug?

Reply #11

I added it just because I was thinking of adding a namespace, but then figured out I didn't find a good one so I gave up.
Anyway, it's jus a character, but will save pain the day we will add a namespace (and for sure we forget about adding the \ :P).
Bugs creator.
Features destroyer.
Template killer.

Re: Another Package Manager Bug?

Reply #12

Quote (and for sure we forget about adding the \ :P).
I forget those all the time, and my whole project is namespaced (PSR-4 FTW :D). Random backslashes stuffed in code look out of place, so I use lots of use statements.
LiveGallery - Simple gallery addon for ElkArte