Fix: Failed to access DBM file when using mod_ruid2 and mod_security

If you are using mod_ruid2 and mod_security on your cpanel server, you may come across a problem if one or more of your mod_security rules use the persistent storage (tracking user IP addresses, etc.). This can be seen in your apache error log file at /var/log/apache2/error_log containing the following lines:


ModSecurity: collection_store: Failed to access DBM file "/var/cpanel/secdatadir/ip": Permission denied

This happens when running apache under mod_ruid2, apache cannot access the ip.pag and ip.dir files located in /var/cpanel/secdatadir/ as the apache process runs as the user and not as nobody.

So far, there’s no proper fix for it, with cpanel saying that the fix has to come from mod_security itself.

Meanwhile to get your rules to work, you can change permissions of the the files, so its writeable by everyone.


# chmod 777 /var/cpanel/secdatadir/ip*

Another problem: Cpanel reverting the above changes

During the daily cpanel update process (upcp), the above files are flushed and regenerated causing the permissions to be reset to the original one. To fix this, you will need to create a cpanel hook that runs right after the daily cpanel update process.

Create a script called resetmodsecperm and store it in the /scripts/ folder.


#!/bin/bash
chmod 777 /var/cpanel/secdatadir/ip.*

Make the script executable


# chmod a+x /scripts/resetmodsecperm

Create a cpanel hook


# /usr/local/cpanel/bin/manage_hooks add script /scripts/resetmodsecperm --manual --category System --event upcp --stage post

What the above does is, you are creating a hook that runs the resetmodsecperm script after (–stage post) the cpanel update process (–event upcp).

So with that done, your mod_sec rules will run properly and not throw errors. I know this is a hacky way and chmodding the files 777 could be risky, but this seems to be the only way to make all mod_sec rules work.

UPDATE: With a recent cPanel update, I have noticed a new script has been added and is made to run every two hours. The script basically shrinks the ip.pag and ip.dir files, but this also reverts the permissions of the files and you get the same error as before.

New entry found in crontab:


0 */2 * * * /usr/local/cpanel/scripts/shrink_modsec_ip_database -x 2>&1

So, in your cron tab, have your script run after the above script.


2 */2 * * * /scripts/resetmodsecperm

This will run your script 2 minutes after every time the ip.pag and ip.dir files are recreated.

May/June 2019 UPDATE:

With the recent EasyApache update from cPanel (29/5/2019, 5/6/2019), modsecurity has been updated from 2.9.2 to 2.9.3. Although modsecurity mentions this new update has fixed compatibility issues with modruid2, some rules do not seem to work.

cPanel has also raised an issue regarding the same problem.

So, until the issue is fixed, a work around is to downgrade modsecurity to 2.9.2 and prevent cpanel from upgrading it:


yum remove ea-apache24-mod_security2

yum install ea-apache24-mod_security2-2.9.2-11.11.7.cpanel.x86_64

Append ea-apache24-mod_security2* to the exclude line in /etc/yum.conf 

 

8 thoughts on “Fix: Failed to access DBM file when using mod_ruid2 and mod_security”

  1. Does not work for me, using modruid2 and modsec 2.9.3 on cpanel centos 7.6 box.
    Followed your instructions.
    I see the file perm change. I do see the ownership of /secdatadir/ is still root:nobody
    The ownership of the files inside this folder are :
    nobody:nobody for : ip.dir ip.pag global.dir global.pag
    However, the cpanel users all have their own files like specificuser-ip.dir
    ownership of these files is
    specificuser:specifiuser
    It does change error in apache log from access denied to ‘ read only file system”
    I also disabled 2 OWASP rules nr 910 and 912, but no luck.
    Any suggestions ?
    Thanks in advance

    1. I can confirm that the recent modsec 2.9.3 update from cpanel does not work when using modruid2.
      Have updated the post.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.