On Mon, 2004-11-29 at 12:54, Arthur Stephens wrote: > >> I am new to SELinux and Fedora 3 - setting up a replacement server for > the one that got hacked > >> I transfered our websites over and discovered I had to have them all > under /usr/www/ > > >>Who or what does tell you this should be this way? /usr/ is the wrong > >>place. This convention has been in place for a while, it's just more challengin now to have Web files other than in /var/www/. If you haven't seen this, it might help some more: http://fedora.redhat.com/docs/selinux-apache-fc3/ Read on for some suggestions. If you are still stuck, drop by #fedora-selinux on irc.freenode.net. > Ok I moved everything under /var/www.. > ran fixfiles > changed everything under httpd.conf to point to /var/www/... > I got the same error messages just different directories > > Being desperate to get this working I copied the error_log from a directory > that was working > ran fixfiles This should have worked if you ran 'fixfiles relabel'. However, 'restorecon -R /var/www/' should achieve the same thing, but much more quickly. Still, that will just set the files to the file type set for /var/www/, as defined in /etc/selinux/targeted/src/policy/file_contexts/file_contexts: /var/www(/.*)? system_u:object_r:httpd_sys_content_t It looks as if the httpd policy needs the logs to be a different type: allow httpd_t httpd_runtime_t : file { create ioctl read getattr lock write setattr append link unlink rename }; ^^^^^^ <- that's what we want to see e.g: ls /var/log/httpd/ -Z -rw-r--r-- root root root:object_r:httpd_runtime_t access_log -rw-r--r-- root root root:object_r:httpd_runtime_t access_log.1 -rw-r--r-- root root root:object_r:httpd_runtime_t access_log.2 -rw-r--r-- root root root:object_r:httpd_runtime_t error_log -rw-r--r-- root root root:object_r:httpd_runtime_t error_log.1 -rw-r--r-- root root root:object_r:httpd_runtime_t error_log.2 ... You can try: chcon -R -t httpd_runtime_t /var/www/*/logs However, this labeling will likely get wiped out the next time restorecon or fixfiles relabel is run. If your intention is to make the logs viewable via public HTTP, you might try moving them to /var/log/httpd/ and then symlinking the files to /var/www/*/logs. The symlinks should be created with httpd_sys_content_t, which is easily readable (just not neccesarily writable or appendable) by httpd. Running restorecon on the moved logs should make it Just Work (TM). > and got avc: denied { append } > (13)Permission denied: httpd: could not open error log file > /var/www/spokanewines.com/logs/error_log. > Unable to open logs > > [root@webmail ~]# cd /var/www/spokanewines.com/logs/ > [root@webmail logs]# ls -alZ > drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . > drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > access_log > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > error_log > > I tried to run > system-config-securitylevel > but there are no references to Boolean options for Apache HTTP > just firewall options. Which version of s-c-sl do you have? AIUI, the SELinux tab is automatically populated depending on what is in your policy. I have 1.4.18-2, fwiw. Regardless, you can set the Booleans on the command line: setsebool httpd_unified true That is a troubleshooting Boolean you can try. Still, your setup should work, if it's just httpd trying to append to the httpd logs, and they are labeled correctly and/or in the correct location. Still, I'm certain that httpd_t can't append to a file that is set to httpd_sys_content_t unless httpd_unified is enabled. This makes me think that your log files are still labeled incorrectly. If all of this fails, you can turn off the SELinux protection for just Apache by using: setsebool httpd_disable_trans true That will disable the transition for httpd, so it will run in the unconfined_t domain like the rest of the non-SELinux protected daemons. If you do that, please don't give up troubleshooting! Your situation should work, and if it doesn't, we all want to figure out why. :) - Karsten -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41