[CentOS] Digest Subcriber needs help with SELinux file context setting

CentOS-5.1

I need some help with setting up the SELinux context for a custom httpd
directory so that I can write log files into it.  This is what I have:

In my virtual host config file:

RewriteEngine   on
RewriteLog      /etc/httpd/virtual.d/trac-rewrite.log
# RewriteLogLevel 0=off 1=basic 2=verbose 3+=module developer debuging
RewriteLogLevel 0

If /etc/httpd/virtual.d/trac-rewrite.log does not already exists then when
I try to start httpd I get this:

--->
# service httpd start
Starting httpd:                                            [FAILED]

Checking /var/log/messages I see this:

# tail /var/log/messages
Dec 17 16:08:01 inet01 setroubleshoot:
      SELinux is preventing the /usr/sbin/httpd from using potentially
mislabeled files trac-rewrite.log (etc_t).
      For complete SELinux messages. run sealert -l
cfc477ae-0443-44f7-9bd3-4ede69b03a57

Following the suggested remedy I do this:

# sealert -l cfc477ae-0443-44f7-9bd3-4ede69b03a57
Summary
    SELinux is preventing the /usr/sbin/httpd from using potentially
mislabeled
    files trac-rewrite.log (etc_t).

Detailed Description
    SELinux has denied the /usr/sbin/httpd access to potentially mislabeled
    files trac-rewrite.log.  This means that SELinux will not allow http
to use
    these files.  Many third party apps install html files in directories
that
    SELinux policy can not predict.  These directories have to be labeled
with a
    file context which httpd can accesss.

Allowing Access
    If you want to change the file context of trac-rewrite.log so that the
httpd
    daemon can access it, you need to execute it using chcon -t
    httpd_sys_content_t.trac-rewrite.log.  You can look at the
httpd_selinux man
    page for additional information.

Additional Information

Source Context                user_u:system_r:httpd_t
Target Context                system_u:object_r:etc_t
Target Objects                trac-rewrite.log [ dir ]
Affected RPM Packages         httpd-2.2.3-11.el5.centos [application]
Policy RPM                    selinux-policy-2.4.6-106.el5_1.3
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.httpd_bad_labels
Host Name                     inet01.hamilton.harte-lyne.ca
Platform                      Linux inet01.hamilton.harte-lyne.ca
                              2.6.18-53.1.4.el5xen #1 SMP Fri Nov 30 01:53:35
                              EST 2007 i686 i686
Alert Count                   4
Line Numbers

Raw Audit Messages

avc: denied { add_name } for comm="httpd" egid=0 euid=0 exe="/usr/sbin/httpd"
exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="trac-rewrite.log" pid=3848
scontext=user_u:system_r:httpd_t:s0 sgid=0 subj=user_u:system_r:httpd_t:s0
suid=0 tclass=dir tcontext=system_u:object_r:etc_t:s0 tty=pts2 uid=0


# chcon -t httpd_sys_content_t trac-rewrite.log
chcon: trac-rewrite.log: No such file or directory

Providing the directory doesn't help either:

# chcon -t httpd_sys_content_t /etc/httpd/virtual.d/trac-rewrite.log
chcon: /etc/httpd/virtual.d/trac-rewrite.log: No such file or directory

But touching the file and running chcon works:

# touch /etc/httpd/virtual.d/trac-rewrite.log[root at inet01 virtual.d]
# chcon -t httpd_sys_content_t /etc/httpd/virtual.d/trac-rewrite.log
[root at inet01 virtual.d]
# service httpd start
Starting httpd:                                            [  OK  ]

What settings in semange or chcon allow me to create files in virtual.d or
should I put them elsewhere.  These files tend to only be used when I am
working on a new set of rules but I would rather not have this tripwire
lurking in the background when I am concentrating on a different type of
problem.

I tried:

# semanage fcontext -a -t httpd_sys_content_t "/etc/httpd/virtual.d(/.*)?"
 and
# semanage fcontext -a -t httpd_sys_content_t "/etc/httpd/virtual.d/*\.log"

But that did not make any difference for the current situation.  If
someone could enlighten me then i would be greatful.

I realize that for some the use of SELinux is controversial. However,
please do not "advise" me to drop SELinux as a remedy for this problem. 
We are not going to do that. Usually, we manage to configure our policies
to handle situations like this as they arise using audit2allow and
audit2why, I just cannot seem to find a way to generalize a solution to
this one.


P.S.  I am a digest subscriber so that message threading is simply not
going to work, Sorry, but that is just the way things are.  For the same
reason I also request the favour of a direct rely in addition to any to
the list.

Sincerely,

-- 
***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3