allow logfile tmpfs_t:filesystem associate; would allow all types marked with
the "logfile" attribute to be created in a tmpfs filesystem.
allow file_type tmpfs_t:filesystem associate; would allow all file types to be
created in a tmpfs filesystem.
What is less clear is why logrotate chooses to create in /tmp vs. creating
the temporary file in /var/log itself, as the latter approach would avoid this
problem as well as avoiding the typical risks associated with using files in
/tmp (due to the fact that any process can create files, including malicious
symlinks, there).

I will add this to policy, but it looks like the requirement for this has been
removed from Rawhide. logrotate-3.7.1-9 is no longer using a script in /tmp.
Peter are we looking at this for an update release?

(In reply to comment #3)
> I will add this to policy, but it looks like the requirement for this has been
> removed from Rawhide. logrotate-3.7.1-9 is no longer using a script in /tmp.
>
> Peter are we looking at this for an update release?
Do u mean logrotate update for RHEL? I think is good to add this policy into RHEL.
Logrotate will stay using /tmp in RHEL.

An update to my original report. I've been using RHEL4 with targeted-policy for
a month now, and applied all updates as they were released. In my original
report I stated that I hadn't tried to reproduce the problem.
Every week I get an e-mail reporting logrotation errors, and every week I find
the messages below (except for the date, of course) at the bottom of
/var/log/messages.1.
Apr 17 03:04:04 nemesis kernel: audit(1113721444.679:0): avc: denied { setgid
} for pid=13380 exe=/usr/bin/python capability=6
scontext=system_u:system_r:mailman_mail_t
tcontext=system_u:system_r:mailman_mail_t tclass=capability
Apr 17 03:04:04 nemesis kernel: audit(1113721444.836:0): avc: denied {
associate } for pid=13378 exe=/usr/sbin/logrotate name=logrotate.HH3tfF
scontext=system_u:object_r:mysqld_log_t tcontext=system_u:object_r:tmpfs_t
tclass=filesystem
I do not use either mailman or mysql, so this behavior comes from the default
configurations as installed by the relevant RPMs.

That actually makes the situation worse. In my original report I note that a
service I don't actually use can't have it's (empty) log rotated. Your proposed
change prohibits me from making use of software that I do use.
After remounting, I tried to use the Pine mail client and was told that the mail
folder was in use and would be accessed in read-only mode. Hmmmm... Looking at
the system log I see this:
May 12 19:22:36 nemesis kernel: audit(1115940156.284:0): avc: denied {
associate } for pid=26203 exe=/usr/bin/pine name=.301.47636
scontext=root:object_r:tmp_t tcontext=system_u:object_r:tmp_t tclass=filesystem
May 12 19:22:36 nemesis pine: Mailbox lock file /tmp/.301.47636 open failure:
Permission denied
Pine is just the first program I tried. Gaining the ability to rotate mysql.log
files (assuming that this is now possible) at the expense of some/all programs
that create temporary files on /tmp seems like a very poor trade-off.

Oh, I've just noticed, the output from "logrotate" command and kernel log are
from two different runs of logrotate. I copy&pasted SELinux log from wrong
messages file. I also have a line in messages file equivalent to the above
complaining about logrotate.y93Js1.