Hi -- Lobanov Igor wrote:
> I've found one problem while using FastcgiAccessChecker directive. All > are working as expected while I'm send GET-requests to Apache. When I > send POST-request request body is truncated. As far as I've understood > this problem was in mod_fastcgi also. Can this be solved so that > request body would be passed untouched or I must look for workaround? I think your problem may be the one I describe below under item #6 (from my email to the list on May 11). There are patches for all of these issues available in the mod_fcgid-1auth-trunk.patch file at this location: http://people.apache.org/~chrisd/patches/mod_fcgid_auth/ I'm not sure any of these fixes have made it into CVS HEAD yet, but as I note below, I found that at least items #3 through #6 were critical problems I had to fix before using FastCgiAuthenticator, FastCgiAuthorizer, or FastCgiAccessChecker. Maybe someone with CVS access could take a look at these before CVS HEAD drifts too far out of sync? Thanks, Chris. -------- Original Message -------- Subject: [PATCH] authn/z fixes Date: Wed, 09 May 2007 17:03:07 -0700 From: Chris Darroch <[EMAIL PROTECTED]> Hi -- Please find below a cumulative patch for a number of issues with mod_fcgid; the patch should apply against CVS HEAD. Some of these are minor but most of them are crucial for anyone using the FastCgiAuthenticator, FastCgiAuthorizer, and/or FastCgiAccessChecker configuration directives. The changes include: 1) Fix a typo in mod_fcgid.c so that FastCgiAuthorizer and FastCgiAuthorizerAuthoritative are defined. 2) Add per-directory configuration merging, as described in my previous email: http://sourceforge.net/mailarchive/message.php?msg_name=46228B54.5060308%40pearsoncmg.com As an example, this allows: <Directory /> FastCgiAuthenticator /my/auth/fcgi </Directory> <Directory /public> FastCgiAuthenticator None </Directory> 3) Fix a serious problem in handle_request() when using FCGI_AUTHORIZER role. The existing code extracts the inode and deviceid from r->finfo and compares these to the inode and deviceid values for all available executing FastCGI processes. If a match is found, then that process is used, otherwise a new one is spawned. The problem is that r->finfo describes the file being requested in the HTTP request. In the FCGI_RESPONDER case, that file is the CGI script, and so the code works. In the FCGI_AUTHORIZER case, though, the file in the request bears no relation to the authorizer script we want to execute. For example, if access control is enabled on all images, then r->finfo and r->filename will describe whatever image the user is requesting (e.g., foo.gif). In this case, the code almost never finds a match in the list of free FastCGI processes, and so it generates a huge number of spawn requests to the procmgr. Each newly spawned process is then recorded using the inode and deviceid of the file that happened to be in the HTTP request (e.g., foo.gif), ensuring that future requests will also virtually never match and the process will never be used again. To fix this problem, my patch passes an auth_conf structure (renamed fcgid_auth_conf) to handle_request from which is can extract the correct inode, deviceid, etc. 4) Fix another problem in handle_request() where the same FastCGI process, if configured to be used in both FCGI_RESPONDER and FCGI_AUTHORIZER modes, will be spawned twice. This is because when no wrapper_conf structure exists, the shareid value for the FCGI_RESPONDER role is set to 0. However, the share_group_id value in all auth_conf structures is set to -1 in the same case (this is done by the set_authenticator_info(), etc. functions). Further, I'm fairly sure the use of 0 also conflicts with a valid wrapper_id. In set_wrapper_config(), apr_pcalloc() is used to allocate the id_info structure, so the first id_info->cur_id and wrapper_id values should be, I think, 0. I didn't test this myself. At any rate, using -1 in handle_request() for the non-wrapper case means that there's a guarantee of no overlap, and a FastCGI process can respond to both FCGI_AUTHORIZER and FCGI_RESPONDER role requests. 5) Fix another problem in handle_request() where any request where the entire body of the FastCGI process's response was not read would cause the process not to be released into the free list until the entire request was complete. This meant that a process used by the authentication phase handler, for example, would be retained in the busy list until the request completed, so it could not be reused in, for example, the authorization or content generation phases. In the normal FCGI_RESPONDER role case, handle_request() would call ap_pass_brigade() and when the final bucket was read from the FastCGI process's output, fcgid_header_bucket_read() would run the bucket_ctx_cleanup() function which would release the process back to the free list. However, if an error occurs, or if after reading just the HTTP headers with ap_scan_script_header_err_core() a redirction is performed, or in the FCGI_AUTHORIZER case where ap_pass_brigade() is never called, the FastCGI process will not be released until r->pool is destroyed at the end of the entire request processing sequence. Anything that uses FastCGI in multiple request processing phases, or in sub-requests or internal redirections, will therefore consume more processes than necessary. To fix this, I moved all the IPC portions of handle_request() into a handle_request_ipc() sub-function, and after invoking handle_request_ipc(), handle_request() always runs the bucket_ctx_cleanup() function before returning; that function is a no-op if it has previously been called on the given fcgid_bucket_ctx structure. [snip] -------- Original Message -------- Subject: Re: [PATCH] authn/z fixes Date: Fri, 11 May 2007 11:30:47 -0700 From: Chris Darroch <[EMAIL PROTECTED]> [snip] 6) The bridge_request() function reads the entire request body from r->input_filters, in order to send it to applications functioning in the FCGI_RESPONDER role. However, in earlier phases of request handling, that's not appropriate; it means the eventual content handler sees no request body data. So bridge_request() now only reads from r->input_filters when functioning in the FCGI_RESPONDER role. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Mod-fcgid-users mailing list Mod-fcgid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
