On Tuesday 28 May 2013 11:28:06 Dominick Grift wrote:
> On Tue, 2013-05-28 at 10:26 +0200, Geert Janssens wrote:
> > type=AVC msg=audit(1369468867.049:94733): avc: denied { search } for
> > pid=7230 comm="awstats.pl" name="www" dev=xvda ino=5832775
> > scontext=system_u:system_r:awstats_t:s0-s0:c0.c1023
> > tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=dir
> >
> > Next I'm confused with the labels. The file is labeled
> > system_u:object_r:httpd_log_t:s0, but the avc seems to complain about
> > system_u:object_r:httpd_sys_content_t:s0
> The awstats.pl command was trying to "traverse" the "(/var/)www"
> directory, which is labeled rightfully httpd_sys_content_t.
>
> I can get all that information (and more) by analyzing the "type=AVC"
> line above.
>
> Either you have "misconfigured" awstats (what business does awstats.pl
> have with webserver content?) or you need to adjust the policy to
> reflect your particular configuration
Thanks for spelling out the AVC for me. But what exactly does "traverse" mean in this context ? Does it simply mean that awstats is trying to access a file somewhere in the tree below /var/www ? Or is it trying to read the contents of /var/www directly for some reason ?
This particular server is hosting websites for multiple clients. Each client has access (via ftps) to a subdirectory somewhere in /var/www. They can use this access to manage their websites.
In addition, to give each client access to the weblogs for his/her own website, we had decided to write logs per website to a log directory inside the client's hosting space. This directory is only accessible via ftps, not via http.
And that's why awstats needs access to /var/www. With the latest security updates something must have changed, because this configuration worked before I applied them.
But regardless of what worked before, what would you suggest as a solution for my situation ?
Geert