Re: Apache 2.x leaked descriptors

From: Christian Kratzer (ck@cksoft.de)
Date: 02/25/03

  • Next message: Steve Grubb: "Re: Apache 2.x leaked descriptors"
    Date: Tue, 25 Feb 2003 18:34:24 +0100 (CET)
    From: Christian Kratzer <ck@cksoft.de>
    To: Brian Hatch <vuln-dev@ifokr.org>
    
    

    Hi,

    On Tue, 25 Feb 2003, Brian Hatch wrote:
    > I'd argue that the error log *should* be available to exec'd CGIs
    > etc. That way the STDERR of a CGI is available to the programmer
    > for debugging purposes. Beats the hell out of printing debugging
    > information to the webbrowser. This has been the case for all the
    > Apache versions I'm familar with.

    file descriptors 0, 1 and 2 are not the problem. They are open and
    required for the script to function properly.

    > Now error log should be opened in append only mode, such that these
    > logs can only grow the error log, not overwrite or truncate. I do
    > not know if this is the case. If there is more than one error log
    > for that apache process, I'd argue that apache should close all
    > of them except the one associated with that program (probably
    > because of the VirtualHost it's associated with, for example.)

    Yes error messages from cgi scripts usually end up in the virtual
    hosts error log. That is current behaviour if I'm not mistaken.

    [snipp]
    > If the error log (the only one that is appropriate for the
    > exec'd program in question) is opened in append only mode, this
    > seems to be appropriate.

    the cgi has access to the error log via its stderr file descriptor 2.
    It does not need access to the file descriptor of the log itself.

    > I think an apache directive to allow
    > all logs to be closed would be a good one, or perhaps a flag
    > to define close on exec when you define your log files.

    the apache source code already has hooks for closing these resources.
    The reason it is not happening is because there is a bug. A trivial
    patch has been posted and is being discussed with the apache group.

    I hope it will get committed into their cvs as soon as possible.

    Greetings
    Christian

    -- 
    CK Software GmbH
    Christian Kratzer,           Schwarzwaldstr. 31, 71131 Jettingen
    Email:	ck@cksoft.de
    Phone: 	+49 7452 889-135     Open Software Solutions, Network Security
    Fax: 	+49 7452 889-136     FreeBSD spoken here!
    


    Relevant Pages

    • Re: STDERR, php://stderr, file_put_contents(), fwrite() questions...
      ... I don't know where you think stderr is available with Unix under Apache - AFAIK, it's not available in PHP, Perl or Java. ... The default is the console if the application has a console attached. ... The Apache stderr error log is NOT the same as a console stderr! ...
      (comp.lang.php)
    • Re: Perl and IIS - script runs but The page cannot be displayed
      ... Look at the server's error log. ... Run the script from a command prompt so you can see ... The FAQ answer points to brian d foy's CGI "Troubleshooting Perl CGI ...
      (comp.lang.perl.misc)
    • Re: perl LibXML
      ... as binary or rpm|deb|pkg package? ... there seems to be an older version of libxml2, namely 2.4.x, and for some ... Try to make sure the cgi finds the newer version of the lib instead of the ...
      (comp.lang.perl.misc)
    • Re: Debug question
      ... blowing up in the CGI. ... How do I send an 'alert' pop-up message while in the CGI? ... server's error log, or put this statement near the top of your program, ...
      (comp.lang.perl.misc)
    • Re: apache problem
      ... I'm unable to reproduce this on my 1.3.26 ... > Subject: Re: apache problem ... > This causes the cpu to reach 100% and the httpd process consumes all ... >> Few minutes before in error log: ...
      (Incidents)