mod_ruid2 may be broken on Rocky Linux 8

[CharlesBNCSU]

I just spent way too long tracking this down and wanted to share in case anyone else hits it.

New cPanel server on Rocky Linux 8. (kernel-4.18.0-477.13.1.el8_8.x86_64)
It installed mod_ruid2 by default. Using mpm-prefork.
WHM and cPanel web services work fine.
Any web request to the hostname or the one vhost that I have always return 500 Server Error and the httpd child process aborts. Every hit.

I eventually discovered that turning off mod_ruid2 solves the aborting problem, but web server returns 403 Forbidden because user 'nobody' cannot read anything.

This issue seems to suggest there's something in the more-recent-than-centos7 kernels that is breaking the libcap calls used by mod_ruid2. Or, it's also possible that the puppet code that I'm porting forward from CentOS 7 is doing things that it shouldn't do to Rocky 8... but I haven't been able to find that if it's true.

The work around that I came to was to remove mod_ruid2 and use mod_suphp instead:
dnf remove ea-apache24-mod_ruid2
dnf install ea-apache24-mod_suphp

 

[cPRex]

Hey there! Let me do some testing with this and I'll get back with you soon!

 

[cPRex]

I wasn't able to reproduce this on a test machine. I created a server running cPanel 112 on RockyLinux 8, created one vhost with a basic PHP Info page, and I was able to load that page normally with mod_ruid2 installed and running. No odd errors were present in the browser or in the Apache error log.

I also am not seeing any similar behavior when I searched our ticket system, so it does seem like this may be an isolated issue with your environment.

 

[CharlesBNCSU]

I wasn't able to reproduce this on a test machine. I created a server running cPanel 112 on RockyLinux 8, created one vhost with a basic PHP Info page, and I was able to load that page normally with mod_ruid2 installed and running. No odd errors were present in the browser or in the Apache error log.

I also am not seeing any similar behavior when I searched our ticket system, so it does seem like this may be an isolated issue with your environment.

Good to know, thanks for following up.

 

[cPRex]

Sure thing!