Project

General

Profile

Actions

Bug #28975

closed

Accessing the extension manager through the backend in a fresh 4.5.x installation fails

Added by Hendrik Becker over 12 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2011-08-15
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
5.2
Tags:
Complexity:
easy
Is Regression:
No
Sprint Focus:

Description

After proper installation of TYPO3 4.5.x accessing the extension manager from the T3 backend fails with a JS-alert-popup: "Unable to get webmail password!".
The messages is originated from the plesk environment the TYPO3 was installed on.
There are probably other misbehaviours on other systems, depending on the server environment.

The problem is caused by the system extension 'em' itself. It tries to require a file named 'conf.php'. Because the requiring uses a relative path, the environments search paths are applied and a plesk file named 'conf.php' is found and included instead of the 'conf.php' that belongs to the 'em' extension.

The Problem can be solved by correcting the file:
typo3/sysext/em/classes/index.php

Change Line 48:
require('conf.php');

Into:
require(t3lib_extMgm::extPath('em') .'classes/conf.php');

Actions #1

Updated by Chris topher over 12 years ago

  • Status changed from New to Needs Feedback

Hi Hendrik,

thanks for your bug report!

I see the problem, but I think your solution is not ideal:
I think you can get this error in nearly every module in TYPO3, because TYPO3 uses exactly this line maybe 100 times or so. Now we could modify each of them, but even if we did, that would not be enough: If you want to install an extension, which does not come with the TYPO3 Core, you have a high chance, that such line is used there, too. So all in all I don't think that modifying the paths is the right solution.

Btw. imagine which harm could be done, if you had an evil PHP script somewhere under the webroot. With your current configuration it obviously is possible to access Plesk files. So one could e.g. steal Plesk login data or such.
This configuration is a security risk and I recommend to fix that.

I would make sure that the PHP include path is correct (or configure Plesk, if it is Plesk which changed this path?). It should first search for files in the current directory. This should solve the issue.

Actions #2

Updated by Hendrik Becker over 12 years ago

Hi Christopher,

you are absolutely right. Luckily it is only a non public testing environment.
To me the confusing fact is, that this issue did not rise in version prior to TYPO3 4.5.0.

In TYPO3 4.4.X the EM was located in a different path, but it also holds the line:

require('conf.php');

which never caused any trouble. Neither did any other extension cause any problems and I am sure they have relative inclusions as well.

But I see the point that it most likely will be a local problem only that has to be fixed locally and should not be fixed within TYPO3.

Actions #3

Updated by Chris topher over 12 years ago

The Extension Manager was rewritten for TYPO3 4.5, but anyway that this does not happen anywhere else is an interesting fact...

Could you solve it by fixing the include_path in php.ini?

Actions #4

Updated by Hendrik Becker over 12 years ago

These are the "include_path" settings from phpinfo() within the TYPO3-Install-Tool:

Local Value:
.:/usr/share/psa-horde/pear:/usr/share/psa-horde/config:/etc/psa-horde/horde

Master Value:
.:/usr/share/psa-horde/pear:/usr/share/psa-horde/config:/etc/psa-horde/horde

Actually it is supposed to look in the current folder first. I did not change this setting, so .. no, the include_path seems to be ok to me and it does not fix the problem. But on the other hand I did not encounter this issue on other servers so far.

The phpinfo also shows these details on the PHP version used:
CONST: php_sapi_name : cgi-fcgi
OTHER: PHP_VERSION : 5.2.0-8+etch16
Server API : CGI/FastCGI

Actions #5

Updated by Chris topher over 12 years ago

Hmm, what is the current working directory?

Actions #6

Updated by Hendrik Becker over 12 years ago

I did some debugging and I think I got the issue straight. Probably results in a TYPO3 security issue though.

I added these lines to the file: typo3/sysext/em/classes/index.php
echo getcwd();
exit;

it outputs this path:
/var/www/vhosts/<domain>/httpdocs/typo3_src-4.5.4/typo3

now that explains why it does not find the conf.php file instantly. But it does not explain why the path is set incorrectly or why it results in a problem on my system. Now the answer is within the PHP documentation: http://ca.php.net/manual/en/function.include.php
The problem is, the path is wrong on all TYPO3 installations, but it still works, because there is no conf.php file found within the php include_path, normally. So the least action php does to try to find a conf.php file is this:
--- FROM PHP DOCUMENTATION start ---
If the file isn't found in the include_path, include() will finally check in the calling script's own directory and the current working directory before failing.
--- FROM PHP DOCUMENTATION stop ---

I also figured that the file: typo3/sysext/em/classes/index.php
is required on line 51 in file: typo3/mod.php

I took a look at that file and the difference between the em-extension and the other extensions at the "Admin tools"-Section is, that only the em-extension seems to explicitely require its own conf.php file.

Now my naive question is, why does the em-extension explicitely require its own conf.php file, if it already is required on line 49 in file: typo3/mod.php

I am sure there is a good reason for doing so, but removing these lines:
unset($MCONF);
require('conf.php');

from file: typo3/sysext/em/classes/index.php
also results in a smooth executing.

Actions #7

Updated by Helmut Hummel over 12 years ago

  • Project changed from TYPO3 Core to 1716
  • Category deleted (Extension Manager)

move to core security project

Actions #8

Updated by Christian Kuhn over 12 years ago

  • Project changed from 1716 to TYPO3 Core

Moved to core again, this is not a direct security issue.

Could however be fixed in 4.5 and above: mod.php should take care of conf.php, so both lines can probably removed. Should however be checked and tested, especially in 4.5 with new and old em.

Actions #9

Updated by Alexander Opitz almost 11 years ago

  • Status changed from Needs Feedback to New
Actions #10

Updated by Mathias Schreiber over 9 years ago

  • Status changed from New to Closed
  • Is Regression set to No

we got rid of conf.php in master.. yay :)

Actions

Also available in: Atom PDF