php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #58970 Incompatible with mod_security2
Submitted: 2009-12-02 13:54 UTC Modified: 2021-10-31 04:22 UTC
From: blepore at igniteworldwide dot com Assigned: cmb (profile)
Status: No Feedback Package: uploadprogress (PECL)
PHP Version: 5.2.6 OS: CentOs
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: blepore at igniteworldwide dot com
New email:
PHP Version: OS:

 

 [2009-12-02 13:54 UTC] blepore at igniteworldwide dot com 
Description:
------------
No temp file is created when mod_security2 is enabled.

Possible cause that I have found is that PHP writes to a different file name in the user's temp directory when mod_security is enabled compared to when it is not.

Sample temp files created when mod_security is disabled:
phpENU1wg
upt_805677.1259779397.txt

where "805677.1259779397" is the UPLOAD_IDENTIFIER.

Sample temp files created when mod_security is enabled:
20091202-144325-SxbDWkU8c54AACEoQmIAAAAF-request_body-TgkMtk

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-12-02 15:06 UTC] blepore at igniteworldwide dot com 
If this cannot be accomplished, it is worth adding to the documentation that setting SecRequestBodyAccess to Off will work around the issue (though leave the site more vulnerable).
 [2010-01-08 03:14 UTC] leahy_rich at hotmail dot com 
Has there been any progress or work arounds to this isssue without changing mod_security2 yet as i am having this problem?
 [2010-01-08 05:06 UTC] chregu@php.net 
The current workaround is mentioned by "blepore at 
igniteworldwide dot com" in the comment above...

I don't have the time nor the intend to dig into that problem 
as I'm not using mod_security
 [2010-02-21 12:47 UTC] php at gileskennedy dot com 
The problem is recognised over at 
https://www.modsecurity.org/tracker/browse/MODSEC-17:

"In order to block 100% reliably we need to buffer; there's 
no 
question about that. However, buffering is not always the 
best, or 
even desired, approach. Some mechanisms (such as file upload 
progress bars) rely on having a free flow of data..."

But that won't be addressed until mod_security 3 and I've 
not found 
any info on when mod_security 3 is likely to be 
released. Very unlikely this year I'd have thought; a 2.6 
release is 
planned first and there's been very little activity on v3 as 
yet. 
https://www.modsecurity.org/tracker/browse/MODSEC?
report=com.atlassian.jira.plugin.system.project:roadmap-
panel
 [2017-10-24 09:01 UTC] kalle@php.net
-Status: Open +Status: Suspended
 [2017-10-24 09:01 UTC] kalle@php.net 
This package has not had any releases for 6 years, so I'm gonna suspend it, any new maintainer that decides to pick this up can re-open this ticket.
 [2020-01-26 01:03 UTC] ramsey@php.net
-Assigned To: +Assigned To: ramsey
 [2020-01-26 01:03 UTC] ramsey@php.net
-Status: Suspended +Status: Assigned
 [2021-10-18 14:13 UTC] cmb@php.net
-Status: Assigned +Status: Feedback -Assigned To: ramsey +Assigned To: cmb
 [2021-10-18 14:13 UTC] cmb@php.net 
> But that won't be addressed until mod_security 3 […]

ModSecurity v3 has been released in the meantime, so I wonder
whether this issue is resolved now.
 [2021-10-31 04:22 UTC] pecl-dev at lists dot php dot net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 16:01:28 2024 UTC