Error: pcfg_openfile

ronaldst

• March 23, 2018 18:36

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_u:eek:bject_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

  • March 26, 2018 14:14

  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.

  0
• 

  goodmove

  • April 03, 2018 01:10

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

  0
• 

  ronaldst

  • April 22, 2018 01:33

  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.

  0
• 

  cPanelMichael

  • April 23, 2018 14:46

  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.

  0
• 

  ronaldst

  • April 23, 2018 22:11

  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)?

  0
• 

  cPanelMichael

  • April 24, 2018 13:41

  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.

  0
• 

  ronaldst

  • April 25, 2018 15:31

  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?

  0
• 

  cPanelMichael

  • April 25, 2018 15:47

  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.

  0
• 

  ronaldst

  • April 30, 2018 22:37

  I made a support ticket for this to have cPanel look at it. [QUOTE]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. [QUOTE]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.

  0
• 

  cPanelMichael

  • May 01, 2018 15:05

  Hello @ronaldst, Thank you for sharing the outcome.

  0

Please sign in to leave a comment.