Error: pcfg_openfile

[ronaldst]

Error log for a few accounts running Wordpress sites are reporting errors regarding pcfg_openfile, file permissions.

[Fri Mar 23 21:31:33.979762 2018] [core:crit] [pid 28095] (13)Permission denied: [client 123.123.123.255:55807] AH00529: /home1/user/public_html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home1/user/public_html/' is executable

# stat /home1/user/public_html
File: ‘public_html/’
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 811h/2065d Inode: 6815757 Links: 12
Access: (0750/drwxr-x---) Uid: ( 1004/ user) Gid: ( 1006/ user)
Context: system_ubject_r:unlabeled_t:s0

# stat /home1/user/public_html/.htaccess
File: ‘public_html/.htaccess’
Size: 4122 Blocks: 16 IO Block: 4096 regular file
Device: 811h/2065d Inode: 6816134 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1004/ user) Gid: ( 1006/ user)

Enable File Protect is enabled in Tweak Settings -> Security.
I ran /usr/local/cpanel/scripts/enablefileprotect, no errors reported.

Any idea what might be causing this and a solution for it?

 

[cPanelMichael]

Hello,

Can you verify which PHP handler is enabled for this account? Also, is Mod_Ruid2 installed? Note that if you are using CGI as your PHP handler, install the suexec module to solve this error:

yum install ea-apache24-mod_suexec

Thank you.

 

[goodmove]

Make sure the 'group' for public_html is set to 'nobody' and the error should go away.

 

[ronaldst]

Sorry about my late reply to this topic.

I am using mod_ruid2, php-fpm, php 7.2 runs with dso as handler.

Do I need to set the public_html to user:nobody? Is 750 the right ownership settings for public_html?

I see several topics where security with dso is mentioned as a concern. Can someone elaborate the flaws with php/dso/php-fpm please? I thought for a long time CGI were the weaker (security wise) option.

 

[cPanelMichael]

Hello @ronaldst,

You can read more about the differences with each PHP handler at:

PHP Handlers - EasyApache 4 - cPanel Documentation

I am using mod_ruid2, php-fpm, php 7.2 runs with dso as handler.

If the account is assigned PHP-FPM, then it doesn't use DSO as it's handler. PHP-FPM takes the place of whichever handler is set as the default for the domain name it's enabled on.

Do I need to set the public_html to user:nobody? Is 750 the right ownership settings for public_html?

On a test system with DSO and Mod_Ruid2, public_html is set with 0750 permissions and user/group ownership is set to the account username.

Thank you.

 

[ronaldst]

Thank you.

I am afraid I am not any wiser. What may be the cause of the error, considering PHP-FPM is active on these domains and file/folder premissions are correct (user:user)?

 

[cPanelMichael]

I am afraid I am not any wiser. What may be the cause of the error, considering PHP-FPM is active on these domains and file/folder premissions are correct (user:user)?

Hello,

Can you also check the permission/ownership values on the /home1 and /home1/username directories? EX:

stat /home1
stat /home1/username

Thank you.

 

[ronaldst]

Thank you.

I'm still getting quite a few errors from users on server. Not only their main public_html/domains but also subdomains are showing errors. Getting a tad frustrating.

# stat /home1/
  File: ‘/home1/’
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 811h/2065d      Inode: 2           Links: 12
Access: (0711/drwx--x--x)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:unlabeled_t:s0
Access: 2018-04-25 17:10:20.593897056 +0200
Modify: 2018-04-25 04:16:51.004552028 +0200
Change: 2018-04-25 05:51:20.420080537 +0200

# stat home1/user1/
  File: ‘home1/user1/’
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 811h/2065d      Inode: 3801089     Links: 23
Access: (0711/drwx--x--x)  Uid: ( 1005/ user1)   Gid: ( 1007/ user1)
Context: system_u:object_r:unlabeled_t:s0
Access: 2018-04-25 17:13:12.216620303 +0200
Modify: 2018-03-10 14:53:27.924743588 +0100
Change: 2018-04-25 05:51:20.423080550 +0200

# stat home1/user1/public_html/
  File: ‘home1/user1/public_html/’
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 811h/2065d      Inode: 3801101     Links: 11
Access: (0750/drwxr-x---)  Uid: ( 1005/ user1)   Gid: ( 1007/ user1)
Context: system_u:object_r:unlabeled_t:s0
Access: 2018-04-25 17:14:33.400962583 +0200
Modify: 2018-04-23 02:29:44.487828777 +0200
Change: 2018-04-25 05:51:20.423080550 +0200

# stat /home1/user1/public_html/subdomain/
  File: ‘/home1/user1/public_html/subdomain/’
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 811h/2065d      Inode: 3801266     Links: 14
Access: (0750/drwxr-x---)  Uid: ( 1005/ user1)   Gid: ( 1007/ user1)
Context: system_u:object_r:unlabeled_t:s0
Access: 2018-04-24 02:05:31.733545839 +0200
Modify: 2018-04-23 02:45:40.919878379 +0200
Change: 2018-04-25 05:51:20.423080550 +0200

I'm using user1 as an example, but I've compared the file permissions/ownership on other users and they are the same for all of them.

Does WHM preserve file/group rights by default? I tried changing a public_html (on a testuser) to user:nobody. It generated no errors while testing, but checking the ownership late on I discovered it was returned to user:user rendering the test useless.

Is there any solution to this with the PHP setup I got (mod_ruid2, php-fpm, php 7.2 runs with dso as handler) ? Is this a PHP-FPM issue?

 

[cPanelMichael]

Hello @ronaldst,

Can you open a support ticket using the link in my signature so we can take a closer look at your system?

Thank you.

 

[ronaldst]

I made a support ticket for this to have cPanel look at it.

Essentially, it looks like some either badly coded, or potentially malicious bots are making non-sense requests to your server, and the user switching of mod_ruid2 does not apply. This leaves apache unable to open the .htaccess files.

However, normal traffic to your server works fine.

In this case, mod_ruid2 is functioning as intended, and preventing apache from being able to read some files while serving requests that could be malicious in nature.

After further investigation in the Apache logs, entries like this (and similar) are found for most of the domains hosted on server:

/etc/apache2/logs/domlogs/domain.com:12.12.12.125 - - [30/Apr/2018:03:19:16 +0200] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 403 - "-" "-"

w00tw00t entries in logs are results of idle or malicious people nosing around looking for vulnerabilities.

Per RFC 2616 § 14.23, your HTTP server should be treating these requests as erroneous, since they are HTTP 1.1 requests without a Host: header. By the logs posted, it appears that it is (status code 403).

Posting results hoping to help others with similar errors/issues.

 

[cPanelMichael]

Hello @ronaldst,

Thank you for sharing the outcome.