selinux-policy-targeted and logrotate

[alex at milivojevic.org]

I've installed selinux-policy-targeted-1.17.30-2.88 from RHEL4 U1 on my system. 
It fixed number of problems with /tmp mounted as tmpfs (and hence having context
of tmpfs_t, instead of tmp_t).  However, I'm still noticing one problem. 
Logrotate postrotate scripts fail.  Log files show it was SELinux blocking
them:

Jun 16 04:02:23 mybox kernel: audit(1118912543.190:0): avc:  denied  { associate
} for  pid=28151 comm=logrotate name=logrotate.8npXq2
scontext=system_u:object_r:var_t tcontext=system_u:object_r:tmpfs_t
tclass=filesystem
Jun 17 04:02:18 mybox kernel: audit(1118998938.340:0): avc:  denied  { associate
} for  pid=6006 comm=logrotate name=logrotate.aNF9be
scontext=system_u:object_r:var_t tcontext=system_u:object_r:tmpfs_t
tclass=filesystem

As I was typing this email, I noticed Daniel already have SELinux/RHEL4/u2
directory, and chagelog indicated problem with logrotate and tmpfs was tackled
after version 1.17.30-2.88 was released.  So I downloaded
selinux-policy-targeted-1.17.30-3.6 and installed it on test system.  I noticed
small problem with postinstall script.  It calls /sbin/restorecon, and it seems
to be relabeling all my file systems as I type this (taking a looong time). 
Not sure if this would be good idea on production systems that might have some
directories with custom labels.  For example, I have chrooted Apache on one of
my systems, and relabeling would destroy it since all the files in chroot jail
would be reset to wrong labels.  Also, if I used chcon to give some application
access to files in non-default area, relabeling entire file system would trash
those too.

Another problem I noticed was that file_contexts and policy.18 files were
created as dot rpmnew, and than restorecon complains about "invalid labels" or
something like that (can't cut&paste it or look exact wording, it scrolled off
very fast, I hardly spotted that newrpm thing).  I guess there are some new
types defined in updated policy, but since policy file was created as rpmnew,
the script simply reloaded old policy file, and kernel didn't knew about new
types.

Anyhow, I believe I had original policy.18 and file_contexts as installed by
previous version of the package.  Shouldn't in this case RPM install new files
instead of creating them as rpmnew?

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.