[OPEN-ILS-DEV] Apache conf improvements

[Joe Atzberger]

Dan Scott wrote:
> 2009/9/3 Joe Atzberger <atz at esilibrary.com>
>>>> Also need to add "a2enmod xmlent", but at a later point after that
>>>> EG-specific piece is compiled and available, before the apache restart.
>>> Hmm. I don't think anyone else has mentioned this as a requirement
>>> before; is that new with trunk?
>> The code is invoking it in eg_vhost.conf is years old, according to git
>> blame:
>>
>> 65769e21 (erickson 2007-02-21 20:35:41 +0000  65)     # - configure mod_xmlent
>> 65769e21 (erickson 2007-02-21 20:35:41 +0000  66)     XMLEntStripPI "yes"
>> 65769e21 (erickson 2007-02-21 20:35:41 +0000  67)     XMLEntEscapeScript "no"
>> 65769e21 (erickson 2007-02-21 20:35:41 +0000  68)     XMLEntStripComments "yes"
>> 65769e21 (erickson 2007-02-21 20:35:41 +0000  69)     XMLEntContentType "text/html; charset=utf-8"
>> 65769e21 (erickson 2007-02-21 20:35:41 +0000  70)     # forces quirks mode which we want for now
>> 65769e21 (erickson 2007-02-21 20:35:41 +0000  71)     XMLEntStripDoctype "yes"
>>
>> It appears that several others have had the same problems, somewhat
>> commonly:
>>
>>   * http://osdir.com/ml/education.libraries.open-ils.devel/2008-07/msg00067.html
>>   * http://www.open-ils.org/irc_logs/openils-evergreen/2009-01/%23openils-evergreen.28-Wed-2009.log
>>   * http://osdir.com/ml/education.libraries.open-ils.devel/2008-09/msg00052.html
>>   * http://markmail.org/message/uxrbalbu4phawhic
>
> Interesting. When mod_xmlent is installed, one of the installation
> steps (I think it's apxs2, actually) adds the following to
> /etc/apache2/httpd.conf:
>
> httpd.conf:LoadModule xmlent_module      /usr/lib/apache2/modules/mod_xmlent.so

Yeah, it looks like that is in my httpd.conf:
#
#LoadModule mod_placeholder /usr/lib/apache2/modules/mod_placeholder.so
LoadModule osrf_json_gateway_module 
/usr/lib/apache2/modules/osrf_json_gateway.so
LoadModule osrf_http_translator_module 
/usr/lib/apache2/modules/osrf_http_translator.so
LoadModule xmlent_module      /usr/lib/apache2/modules/mod_xmlent.so

And my apache2.conf does have "Include /etc/apache2/httpd.conf" too, so 
that would seem consistent.  I don't know if the step to append to those 
lines failed initially or not.  Or maybe there is a timing issue with 
the startup script?

> Cool. Here's one problem - from apache's error.log when I make the
> Apache user run as www-data instead of opensrf:
>
> """
> Connection to Settings Failed  Cannot sysopen
> /openils/var/log/osrfsys.log: Permission denied at
> /usr/local/share/perl/5.10.0/OpenSRF/Utils/Logger.pm line 261.
>  : Cannot sysopen /openils/var/log/osrfsys.log: Permission denied at
> /usr/local/share/perl/5.10.0/OpenSRF/Utils/Logger.pm line 261.
> """
>
> ... because, of course, "chown -R opensrf:opensrf /openils" is one of
> the  final installation steps.
Interesting.  That line would be:

    sysopen( SINK, $file, O_NONBLOCK|O_WRONLY|O_APPEND|O_CREAT )
        or die "Cannot sysopen $logfile: $!";

There's an error there, inasumuch as $file != $logfile, so the error 
message could be misleading.  But in your case, they're identical, so 
this issue must be easy to reproduce:

    perl -we 'use strict; use FileHandle;
    my $file=q(foo.txt);
    sysopen(SINK, $file, O_NONBLOCK|O_WRONLY|O_APPEND|O_CREAT) or die
    qq(Cannot sysopen $file: $!);
    print SINK scalar localtime, qq(\n);'


With the right foo.txt (or directory) owner/permissions, that does it.  
So solutions would include:

   1. chmod g+x /openils/var/log && chgrp www-data /openils/var/log  
      #short term
   2. log to /var/log/apache/xxx instead # where the normal user:group
      aren't a problem
   3. use a log framework like Sys::Syslog or log4perl   # long term

Or is there a more fundamental problem?  Are we actually trying to write 
to the same log file for actions initiated by the web (by "www-data") 
and also those initiated by other actions (via cronjob or command-line 
as another user)?  Unless the logs are passed through a daemon, there 
wouldn't be any real fix for that.
> That might be all there is to it (resolvable by adding www-data to the
> opensrf group?), or there might be more beyond that. Once you peel
> back that layer, though, especially on a machine with multiple
> applications and multiple users, one might get a little concerned
> (either way we approach it) by Apache having read access to all
> Evergreen files.
>
> For example, /openils/conf/live-db-setup.pl and
> /openils/conf/opensrf_core.xml and /openils/conf/opensrf.xml all have
> lots of nifty passwords; if a vulnerable application can be coaxed
> into displaying their contents, hilarity / misery can quickly ensue
You're not suggesting that having apache run as the owner of those files 
somehow makes them more secure, though, right?

--Joe