Awstats search access denied

[Manuel Wolfshant]

On 05/28/2013 02:11 PM, Dominick Grift wrote:
> On Tue, 2013-05-28 at 11:59 +0200, Geert Janssens wrote:
>> 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 ?
>>
> The former. (trying to get to a object below /var/www. search means "to
> traverse". if awstats.pl would list the www directory then you would see
> "read" or "dir" instead of "search" on "dir"
>
>
>> 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.
> The question remains: what business does " awstats.pl "  have
> below /var/www. That needs to be determined. Then we can determine
> whether the file(s)that awstats.pl is trying to get to, should be there
> in the first place. For example: its usually not a good idea to store
> logs in a webroot.
>
>> 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.
> That may well be yes
>
>> But regardless of what worked before, what would you suggest as a solution for my situation ?
> It really depends on what awstats.pl is trying to do there
It's trying to reach and parse the logs