Bug 569360

Please, I am still awaiting updates - I don't want to correct config files by hand in 20 servers and then back when update is released.

This has been broken now in EPEL for over two months. Can we expect a fix anytime soon?

mod_security-2.5.12-2.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/mod_security-2.5.12-2.el5

mod_security-2.5.12-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/mod_security-2.5.12-2.fc12

Give this release a go - it was also undefined in the upstream config, I've added it and some other directives in the main config.

Created attachment 410167 [details]
add missing chain action in modsecurity_crs_30_http_policy.conf

Maybe this should be opened under a different bug id, but since the bug crept in with the latest upstream release, I'll mention it here...

There's a bug in one of the crs files, specifically a missing "chain" action in one of the rule chains, which causes the last rule to be acted on independently. This results in lots of false positives.  (See attached patch.)

mod_security-2.5.12-2.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mod_security'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/mod_security-2.5.12-2.fc12

With mod_security-2.5.12-2.fc12 I see the following in error_log:

ModSecurity: Failed to access DBM file "/etc/httpd/logs//global": Permission denied
Failed to access DBM file "/etc/httpd/logs//ip": Permission denied

/etc/httpd/conf.d/mod_security.conf has "SecRequestBodyLimit 131072" after Include modsecurity.d/modsecurity_localrules.conf, and because of that SecRequestBodyLimit setting in modsecurity_localrules.conf doesn't work.

Could please anyone fix this package or just revert to the last working one, 2.5.10-2 IIRC?

mod_security-2.5.12-3.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/mod_security-2.5.12-3.fc12

mod_security-2.5.12-3.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/mod_security-2.5.12-3.el5

mod_security-2.5.12-2.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/mod_security-2.5.12-2.fc13

mod_security-2.5.12-3.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mod_security'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/mod_security-2.5.12-3.fc12

mod_security-2.5.12-2.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mod_security'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/mod_security-2.5.12-2.fc13

mod_security-2.5.12-3.el5 has been pushed to the Fedora EPEL 5 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mod_security'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/mod_security-2.5.12-3.el5

Unfortunately moving Include modsecurity.d/modsecurity_localrules.conf to the end of file did not help (although the move itself is correct) - even if I have SecRequestBodyLimit 10000000 in modsecurity.d/modsecurity_localrules.conf, SecRequestBodyLimit 131072 in mod_security.conf takes precedence. I have to comment it out. So I don't know if SecRequestBodyLimit, SecResponseBodyLimit should be set in mod_security.conf, what do others think?
BTW, mod_security-2.5.9 had SecRequestBodyInMemoryLimit 131072 in modsecurity_crs_10_config.conf.

Permissions problem with global and ip still remains:
ModSecurity: Failed to access DBM file "/var/log/httpd//global": Permission denied
Failed to access DBM file "/var/log/httpd//ip": Permission denied

/var/log/httpd is owned by root:root and perms are 40700.
mod_security-2.5.9 had SecDataDir /tmp and SecTmpDir /tmp in modsecurity.d/modsecurity_crs_10_config.conf.

+1 on the last comment... SecDataDir needs to point to a directory with proper permissions.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

As F14 package does not differ from F12 (except binaries) I suggest changing version to 14. This bug can probably be closed after fixing SecDataDir (setting it to /tmp for example).

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Please change version to 14 and reopen.

Reopened and changed to F14, as requested.

I'm running F13 (updated) and was seeing the following when running SVN:

[Sat Dec 25 12:26:39 2010] [error] [client 127.0.0.1] ModSecurity: Unable to retrieve collection (name "ip", key "127.0.0.1"). Use SecDataDir to define data directory first. [hostname "localhost"] [uri "/svn/astlinux/!svn/act/290cb8e4-9c76-43d1-80aa-021f3193cb3a"] [unique_id "TRZFb8CoAQoAADwEH2YAAAAF"]
...
[Sat Dec 25 13:45:48 2010] [error] [client 127.0.0.1] ModSecurity: Warning. Operator LT matched 20 at TX:inbound_anomaly_score. [file "/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_60_correlation.conf"] [line "31"] [msg "Inbound Anomaly Score (Total Inbound Score: 15, SQLi=, XSS=): Method is not allowed by policy"] [hostname "localhost"] [uri "/svn/astlinux/trunk"] [unique_id "TRZX-MCoAQoAAFn1aMYAAAAB"]

Hi, Philip!
In /etc/httpd/conf.d/modsecurity.conf add the following entry:
SecDataDir /tmp
That will solve the first error. To solve the second you might comment out the line number 31 in /etc/httpd/modsecurity.d/base_rules/modsecurity_crs_60_correlation.conf. However the rule there is on purpose so I recommend you to read a bit about these rules. Google is your friend!

mod_security-2.5.12-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mod_security-2.5.12-2.el6

Package mod_security-2.5.12-2.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing mod_security-2.5.12-2.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/mod_security-2.5.12-2.el6
then log in and leave karma (feedback).

mod_security-2.5.12-3.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

mod_security-2.5.12-2.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

SecDataDir problem is still not fixed! Please reopen.

This still insn't solved, I still get this error in cenots 5.2
ModSecurity: Failed to access DBM file "/var/log/httpd//global": Permission denied
ModSecurity: Failed to access DBM file "/var/log/httpd//ip": Permission denied

are global and ip files? Where suppose to be? what permission and which ovner of files?

Re-assigning to EPEL 5

There's an upstream bug filed against modsecurity but it's not getting any attention.

What's the link for that bug?

I am also facing this problem for a couple of days now, running EL6 with mod_security-2.5.12-2.el6.x86_64:

ModSecurity: Failed to access DBM file "/etc/httpd/logs/global": Permission denied 
ModSecurity: Failed to access DBM file "/etc/httpd/logs/ip": Permission denied

Permissions on the {global,ip} files and/or SELinux seems not to be the problem.

Where can I find the upstream bug filed against modsecurity? If more people are complaining it might get attention.

(In reply to comment #35)
> Where can I find the upstream bug filed against modsecurity? If more people are
> complaining it might get attention.

It's marked in the "URL" field.

If this is also a problem on the EPEL 6 branch, please adjust the "Version" field for this bug to be EPEL 6.

(In reply to comment #36)

> If this is also a problem on the EPEL 6 branch, please adjust the "Version"
> field for this bug to be EPEL 6.

Since Fedora (and rawhide) are both upstream of EPEL, please leave the version alone so it gets fixed in *all* applicable versions.

mod_security_crs-2.2.6-3.fc18, mod_security-2.7.1-3.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/mod_security_crs-2.2.6-3.fc18,mod_security-2.7.1-3.fc18

mod_security_crs-2.2.6-3.fc17,mod_security-2.7.1-3.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mod_security_crs-2.2.6-3.fc17,mod_security-2.7.1-3.fc17

mod_security-2.7.1-3.el6,mod_security_crs-2.2.6-3.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/mod_security-2.7.1-3.el6,mod_security_crs-2.2.6-3.el6

I just pushed 2.7.1-3 to testing which should fix this issue, can you confirm please.

Package mod_security-2.7.1-3.el6, mod_security_crs-2.2.6-3.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing mod_security-2.7.1-3.el6 mod_security_crs-2.2.6-3.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-13478/mod_security-2.7.1-3.el6,mod_security_crs-2.2.6-3.el6
then log in and leave karma (feedback).

mod_security-2.6.8-2.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/mod_security-2.6.8-2.el5

mod_security_crs-2.2.6-3.fc18, mod_security-2.7.1-3.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

mod_security_crs-2.2.6-3.fc17, mod_security-2.7.1-3.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

mod_security-2.6.8-2.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

mod_security-2.7.1-3.el6, mod_security_crs-2.2.6-3.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.