Project

General

Profile

Actions

Bug #75395

closed

EXT:form – attachments from fileupload missing in mail because of isAllowedAbsPath

Added by Benjamin Robinson about 8 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Form Framework
Target version:
-
Start date:
2016-04-04
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
7
PHP Version:
7.0
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

The attachments from fileupload fields are missing in the confirmation mail.

There's a dirty workaround (related to a Strato webspace) at https://forum.typo3.org/index.php/t/203279/ which resolves this issue.
For Typo3 7.6.4 remove line 445 ...

&& GeneralUtility::isAllowedAbsPath($file['tempFilename'])
... from /sysext/form/Classes/PostProcess/MailPostProcessor.php

I found out the the issue also occurs with webspaces of other providers, f.e. Mittwald, so I'm not sure if it's a bug or the result of an unrecommended PHP-configuration.
If the cause is a special PHP configuration, I would suggest to create an additional Install Tool "System environment check" and bring out, that this configuration will cause trouble with attachments.

My test environment:
Blank new "Webhosting XL 9.0" package from Mittwald.
Template Setup:

page = PAGE
page.10 < styles.content.get

Include static (from extension)
CSS Styled Content (css_styled_content)
Default TS (form)

Form CE Configuration
enctype = multipart/form-data
method = post
prefix = tx_form
confirmation = 
postProcessor {
    1 = mail
    1 {
        recipientEmail = me@example.com
        senderEmail = noreply@example.com
    }
}
10 = TEXTLINE
10 {
    name = textfield
    label {
        value = Textfield
    }
}
20 = FILEUPLOAD
20 {
    name = fileupload
    label {
        value = Fileupload
    }
}
30 = SUBMIT
30 {
    name = 4
    value = Send
}


Files

mittwaldTYPO3FileUploadTest.php (7.43 KB) mittwaldTYPO3FileUploadTest.php Ralf Zimmermann, 2016-06-15 17:38

Related issues 1 (0 open1 closed)

Is duplicate of TYPO3 Core - Bug #70106: Temporary files are not deleted even though GeneralUtility::unlink_tempfile is calledClosed2015-09-25

Actions
Actions #1

Updated by Björn Jacob about 8 years ago

  • Category set to Form Framework

Thx for your detailed bug report. We will investigate the problem.

Actions #2

Updated by Gernot Leitgab almost 8 years ago

I think that the file is not uploaded to a path within PATH_site, but to upload_tmp_dir as configured in php.ini - therefore GeneralUtility::isAllowedAbsPath() fails. Instead of removing the condition in the core you can add an allowed path with the $GLOBALS['TYPO3_CONF_VARS']['BE']['lockRootPath']-setting in your configuration.

Actions #3

Updated by Benjamin Robinson almost 8 years ago

I just tried it with a file "test.pdf" :
The upload_tmp_dir is /tmp according to PHP-Info. The uploaded file was not in /tmp but i found it in /html/typo3/typo3temp/ with the temporary filename upload_temp_v5DrHo .
/typo3temp/ should be a valid "isAllowedAbsPath", or?

Actions #4

Updated by Björn Jacob almost 8 years ago

  • Status changed from New to In Progress
  • Assignee set to Ralf Zimmermann
Actions #5

Updated by Ralf Zimmermann almost 8 years ago

This happens through the chroot environment of mittwald & co.

After a fileupload ext:form move the file from the PHP upload_tmp_dir to /TYPO3DocRoot/typo3temp/.
This is done with the GeneralUtility::upload_to_tempfile function.
The file name is assembled as follows:

$temporaryPath = PATH_site . 'typo3temp/';
$tempFileName = tempnam($temporaryPath, 'upload_temp_');

The return value is a filename like /TYPO3DocRoot/typo3temp/upload_temp_LOx71V.
ext:form use this filename to handle the fileupload / email processing.
As you mentioned the MailPostProcessor use GeneralUtility::isAllowedAbsPath() to check the file path.
isAllowedAbsPath() check if the first part of the string is equal to PATH_site.
If not, the uploaded file will not be attached to the email.

Lets take a look in the Mittwald environment:

PATH_site is build through the Bootstrap process and detected as follow:

PATH_site: '/home/www/pSomeNumber/html/stage/'
Thats because the variable $_SERVER['SCRIPT_FILENAME'] is '/home/www/pSomeNumber/html/stage/'

Now take a look what SplFileInfo says:

$_SERVER['SCRIPT_FILENAME']->getPath(): /home/www/pSomeNumber/html/stage/
$_SERVER['SCRIPT_FILENAME']->getRealPath(): /html/stage

Realpath is /html/stage and not /home/www/pSomeNumber/html/stage/.

Let us go back to GeneralUtility::upload_to_tempfile.

$temporaryPath = PATH_site . 'typo3temp/';
// $temporaryPath = '/home/www/pSomeNumber/html/typo3temp/'
$tempFileName = tempnam($temporaryPath, 'upload_temp_');
// $tempFileName = '/html/stage/typo3temp/upload_temp_LOx71V'

The PHP function tempnam() translate the $temporaryPath to the realpath which is '/html/stage/...'.
the first part of the string '/html/stage/...' is NOT equal to PATH_site.
Thats why GeneralUtility::isAllowedAbsPath() return FALSE and the uploadfile will not be attached.

I'm not exactly sure if TYPO3\CMS\Core\Core\SystemEnvironmentBuilder::getPathThisScriptNonCli() fails or
the mittwald setup.

You can test this issue with the attached test script.

Actions #6

Updated by Benjamin Robinson almost 8 years ago

Thanks! I just tested it and the output is:

$_SERVER['SCRIPT_FILENAME']: /home/www/p123456/html/typo3/test.php
$_SERVER['SCRIPT_FILENAME']->getPath(): /home/www/p123456/html
$_SERVER['SCRIPT_FILENAME']->getRealPath(): /html/typo3
getcwd(): /html/typo3
PATH_site: /home/www/p123456/html/typo3/
upload file tmp name: /tmp/php5Bu6Ub
GeneralUtility::tempnam after PHP tempnam():
/html/typo3/typo3temp/upload_temp_P2MHW3

filename after moving to TYPO3 temp: /html/typo3/typo3temp/upload_temp_P2MHW3

Actions #7

Updated by Björn Jacob almost 8 years ago

  • Status changed from Needs Feedback to Accepted
  • Assignee deleted (Björn Jacob)

This issue is a problem and we have to tackle it.

Actions #8

Updated by Helmut Hummel almost 8 years ago

Bjoern Jacob wrote:

This issue is a problem and we have to tackle it.

I don't see the problem, sorry.

The PHP function tempnam() translate the $temporaryPath to the realpath

This function is not used (any more) in GeneralUtility::upload_to_tempfile(). So where is the "realpath" generated in ext:form?

Actions #9

Updated by Arne-Kolja Bachstein over 7 years ago

Can confirm this on Profihost, too.

Additionally, the dirty workaround (commenting out && GeneralUtility::isAllowedAbsPath($file['tempFilename'])) works.

Tested it with TYPO3 CMS 7.6.12.

Actions #10

Updated by Ralf Zimmermann over 7 years ago

Helmut Hummel wrote:

This function is not used (any more) in GeneralUtility::upload_to_tempfile(). So where is the "realpath" generated in ext:form?

7.6
https://github.com/TYPO3/TYPO3.CMS/blob/TYPO3_7-6-12/typo3/sysext/core/Classes/Utility/GeneralUtility.php#L4070

current master
https://github.com/TYPO3/TYPO3.CMS/blob/015f3bdae52c0e6e03f351fd49c293b201d78bc8/typo3/sysext/core/Classes/Utility/GeneralUtility.php#L3474

Actions #11

Updated by Helmut Hummel over 7 years ago

  • Status changed from Accepted to Needs Feedback

Ralf Zimmermann wrote:

Helmut Hummel wrote:

This function is not used (any more) in GeneralUtility::upload_to_tempfile(). So where is the "realpath" generated in ext:form?

7.6
https://github.com/TYPO3/TYPO3.CMS/blob/TYPO3_7-6-12/typo3/sysext/core/Classes/Utility/GeneralUtility.php#L4070

Please look carefully at the code! It says self::tempnam not tempnam

And \TYPO3\CMS\Core\Utility\GeneralUtility::tempnam does use PATH_site and does not use any realpaths:

https://github.com/TYPO3/TYPO3.CMS/blob/TYPO3_7-6-12/typo3/sysext/core/Classes/Utility/GeneralUtility.php#L4113

Actions #12

Updated by Helmut Hummel over 7 years ago

  • Status changed from Needs Feedback to Accepted

Ah sorry.

A few line below, I now spotted the tempnam:

https://github.com/TYPO3/TYPO3.CMS/blob/TYPO3_7-6-12/typo3/sysext/core/Classes/Utility/GeneralUtility.php#L4115

The only way to solve this (imho), is to do a realpath() call when creating the constant PATH_site

This could be breaking though. Needs to be carefully evaluated

Actions #13

Updated by Helmut Hummel over 7 years ago

Helmut Hummel wrote:

The only way to solve this (imho), is to do a realpath() call when creating the constant PATH_site

Or to only use the core implementation of tempnam: https://github.com/TYPO3/TYPO3.CMS/blob/015f3bdae52c0e6e03f351fd49c293b201d78bc8/typo3/sysext/core/Classes/Utility/GeneralUtility.php#L3524-L3528

Actions #14

Updated by Helmut Hummel over 7 years ago

closed as duplicate. see fix in other ticket

Actions #15

Updated by Helmut Hummel over 7 years ago

  • Status changed from Accepted to Closed
Actions

Also available in: Atom PDF