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
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
