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&gt;&amp;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”
csf not blocking ip address
ok, it’s works
thanks for the updates !!
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
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
I can confirm that the recent modsec 2.9.3 update from cpanel does not work when using modruid2.
Have updated the post.
Does the Dec 5, 2018 release of ModSecurity v2.9.3 help in any way? The release notes indicate that the update addresses mod_ruid2 incompatibility.
https://github.com/SpiderLabs/ModSecurity/issues/1334 (closed as a duplicate of #712)
There are issues with 2.9.3 which makes some rules not work/log. Have updated the post.
thanks for the tricks !!