6

I have recently upgraded my Apache2 server, and am now unable to run a CGI app. My logs are showing

(13) Permission denied unable to connect to cgi deamon after multiple tries

I understand that the error message means Apache is being denied some permission to some file, and I'm stumped as to how to track down and solve the problem.

Is the file mentioned in the error message truly the blocked file? Or might the problem be caused by some other needed file? The .cgi file is right where it has always been, under /usr/share. The file ownership (root) and permissions (world readable/executable) are the same as they have always been for the file and its ancestors. The SELinux file labels are unchanged.

The SELinux audit log shows no denial associated with Apache nor the CGI program. In case of a donotaudit condition, I enabled audit, but still saw nothing. I switched SELinux into permissive mode briefly, to no avail. I even tried restarting Apache while in permissive mode. This did not solve the problem.

Any suggestions on how to solve this problem? I'm tempted to just revert to the older Apache.

TheMeddlingMonk
  • 23
  • 3
user43403
  • 163
  • 1
  • 1
  • 3

8 Answers8

3

may or may not work, seems highly unlikely, but someone had a similar problem, and this was the solution;

chmod 755 /var/log/httpd/ or whatever the directory for apache's logs is, on your server.

http://www.mail-archive.com/apache-fp@lists.joshie.com/msg00585.html

cpbills
  • 2,692
  • 17
  • 12
  • 1
    The permissions for the log directory were fine. However the permissions for its parent directory were not. Relaxing those permissions solved the problem. Yes, it seemed highly unlikely, but it worked. Thanks. It would be nice if Apache's error message wasn't misleading. It had nothing at all to do with the permissions of the .cgi file, as the message claimed (and as I suspected). – user43403 May 19 '10 at 23:38
  • Thank goodness I found this. I had this exact same issue and this was the only solution. To clarify for any future readers: the issue isn't logs per se but the directory containing the Unix socket used by CGID. The Apache user must have write access to this directory. – Dan Jun 28 '10 at 21:45
  • It worked like a charm. CGI sockets are created under that directory. By default parent directory has read, write, execute to only the user. If we grant 755 the web user is able to access the socket under /var/log/httpd/. –  Jul 08 '15 at 05:23
2

Whilst this is an older question, I thought I would add my answer, as I have had little success finding a proper explanation or solution on the Internet.

I have had this issue occur on RHEL 7 with Apache 2.4 (installed as the httpd24 package) only when using the event MPM (the prefork MPM worked fine). SELinux was already set to permissive.

Based on the comment about the CGI sockets, I checked the documentation:

Essentially the CGI daemon when using mpm-event requires a socket file. As Apache runs under user apache and group apache on my server (and no doubt many others), the folder containing this socket file must have read-write access by apache.apache.

Not wanting to override the log folder permissions, I chose to explicitly set the ScriptSock directive in conf.modules.d/00-mpm.conf:

ScriptSock /var/run/httpd/cgid.sock

I then ensured that the httpd directory existed (note: you need to configure this via tmpfiles.d, as /var/run is a tmpfs) and changed the ownership to apache.apache. Permissions were left as the default 755.

This resolved the issue for me.

TheMeddlingMonk
  • 23
  • 3
2

confirm that you have below settings in 00-mpm.conf

/etc/httpd/conf.modules.d/00-mpm.conf

and comment out mod_mpm_prefork.so then comment mod_mpm_worker.so module

LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
#LoadModule mpm_worker_module modules/mod_mpm_worker.so
#LoadModule mpm_event_module modules/mod_mpm_event.so
Amin
  • 121
  • 4
0

I tried many things:

  • setting ScriptSock in apache conf
  • setting permissions for /var/run/httpd/sock file
  • setting permissions for apache log folder
  • setting permissions for perl script, that I want to execute
  • I found mod_cgid.c file and exact function where error is called .. it didn't help me

for me it works, when I set DefaultRuntimeDir in apache conf

pooler
  • 101
0

When executing a cgi script, if selinux is enabled, the selinux context have to be set on the directories and the script files to something like

system_u:object_r:httpd_sys_script_exec_t:s0

you can read the files context with ls -laZ and change them with the chcon command.

For reference, e.g. on rhel distros, we can survey the default cgi script context with the following command:

$ls -aZ /var/www/cgi-bin
system_u:object_r:httpd_sys_script_exec_t:s0 .      system_u:object_r:httpd_sys_content_t:s0 ..
simonarame
  • 109
  • 3
0

I have had module behavior change across apache upgrades. It is possible that your apache conf directives may need some changes to properly serve up your cgi. Without knowing the apache conf and the details of the cgi and it's location on the filesystem, its really hard to do more than just speculate.

Also if you do suspect SELinux, try disabling it to see if apache starts serving the CGI again. If it does then you can start focusing your efforts on either adjusting the policy to allow what you're trying to do or bringing your system into compliance with the SELinux policy.

Mark Carey
  • 151
  • 2
  • I was close to tracking down the cgi module's change log, as this had occurred to me. I had ruled out SELinux as the culprit by putting it into permissive mode. Permissive mode allows everything (like disabled), but still logs would-be violations (unlike disabled). – user43403 May 19 '10 at 23:41
0

AIX 7 had same problem. set permissions on /var/log/httpd directory to fix.

Andy
  • 1
0

The error is not specific to any particular file or directory. This is the error pattern, which does not contain any clues as to which permission is root cause.

... [cgid:error] ... (13)Permission denied: ... AH01257: unable to connect to cgi daemon after multiple tries: ... referer: ...

If the above pattern appears in the httpd log entries but selinux audit logs are clean, then the issue is SOME access rights related to the CGI daemon, not the files listed in the error message. The CGI daemon must be able to locate and write to multiple things.

  • The socket mod_cgid uses to avoid forking children to run CGI scripts
  • The log file mod_cgid uses
  • Possibly other files

The mpm_event_module is now often specified at httpd compilation time in most packages, which causes httpd to default to mod_cgid instead of mod_cgi.

Any of the suggestions in the other answers may work, or they may not. For instance, another case encountered was when we created a group "sites" so that specific users could access site content without loosening other permissions. The /var/run directory had "apache" as its group, which created a permissions denial when trying to create the socket.

Douglas Daseeco
  • 101
  • 1