Re: Awstats search access denied
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