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