On Mon, 2005-31-01 at 12:12 -0500, Colin Walters wrote: > Have you seen the Fedora Apache/SELinux guide? > http://fedora.redhat.com/docs/selinux-apache-fc3/ Yes, I read that when I started to migrate SugarCRM from a FC1 box to a FC3 server, so I'm familiar with selinux. But, probably not enough to figure out what's wrong right now. > > avc: denied { getattr } for pid=681 exe=/usr/bin/perl path=/var/log > > dev=dm-5 ino=129025 scontext=root:system_r:httpd_sys_script_t > > tcontext=system_u:object_r:var_log_t tclass=dir > > Hmm. Given that we allow access to httpd_log_t which is in the default > configuration a subdirectory of var_log_t, I'm surprised that this > access is not allowed. Ideally though the app should not need this. In RT, you can define a separate log file instead of having everything dumped to /var/log/messages. I haven't tried yet, but I'm assuming if I disabled the separate log file, this error would disappear. I would rather keep /var/log/rt.log. It makes reading the log a lot easier since it will only contain messages pertaining to RT. > > avc: denied { ioctl } for pid=693 exe=/usr/bin/perl > > path=/var/log/httpd/error_log dev=dm-5 ino=129070 > > scontext=root:system_r:httpd_sys_script_t > > tcontext=system_u:object_r:httpd_log_t tclass=file > > This one is probably harmless; I think perl does an ioctl even on > regular files in many situations (to find out whether it's a tty?). I'll have to look into it. > > avc: denied { read } for pid=693 exe=/usr/bin/perl name=tmp dev=dm-3 > > ino=12 scontext=root:system_r:httpd_sys_script_t > > tcontext=system_u:object_r:tmp_t tclass=lnk_file > > Is this /usr/tmp? Try running "chcon -h -t usr_t /usr/tmp". This is a > bug in our policy package because it doesn't presently ensure that it's > relabeled on upgrades. Actually, it's just /tmp. FastCGI dumps its temporary files there while it's running. The location can be changed, but in the past (on FC1) when I've tried using /var/log/httpd/fastcgi, I just get a bunch of errors about FastCGI not having permission to write to that directory (I believe the only way I managed to fix that was by changing permissions on /var/log/httpd to 777). The command you mentioned above won't work in this case, will it? I'm assuming that context is meant only for directories under /usr. Thanks, Ranbir -- Kanwar Ranbir Sandhu Linux Consultant Systems Aligned Inc. www.systemsaligned.com
