Bug 65984

Summary: `fcgi_check_authn` (or rather `handle_response`) appears to be not robust to flush on socket
Product: Apache httpd-2 Reporter: dorian <code>
Component: mod_authnz_fcgiAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: NEW ---    
Severity: normal    
Priority: P2    
Version: 2.4.41   
Target Milestone: ---   
Hardware: All   
OS: All   
Attachments: try this script with the flush lines commented vs uncommented

Description dorian 2022-03-30 01:16:24 UTC
Created attachment 38237 [details]
try this script with the flush lines commented vs uncommented

I am in the process of writing an authentication module[1] that avails itself of mod_authnz_fcgi[2] to complement the necessary behaviour. The FastCGI authenticator[3] is expected to send content (e.g. 401 error pages) when authentication fails. This currently does not happen. What happens instead is the default Apache error page is displayed[4] and the body content coming from the authenticator is discarded.

In order to diagnose this situation, I created two separate, stripped-down FastCGI scripts that only return a 401 with a body message, one in Ruby and one in Perl. Both functioned as expected. Upon looking at the Rack::Handler::FastCGI source I noticed that it flushes its output after the headers and again after each body chunk, and changed the stripped-down scripts to mimic it. This change yielded the same body-discarding behaviour as the Rack version.

What appears to be happening, then, is mod_authnz_fcgi is abandoning its socket to the FastCGI authenticator after the latter flushes the socket.

Footnotes:

1) Using Ruby and Rack (https://github.com/doriantaylor/rb-lazyauth), though in principle this detail doesn't matter.

2) Note that the Apache version selected for this report is the one where this behaviour was observed (i.e., that ships with Ubuntu 20.04 LTS).

3) https://httpd.apache.org/docs/2.4/mod/mod_authnz_fcgi.html#authnzfcgicheckauthnprovider

4) The error pages' Content-Type header overrides whatever comes out of the FCGI authenticator no matter what, but that is probably a separate issue.