Bug 127313

It also mails large files about fixing the /dev/* files to root.

There is an easy fix:
after sourcing /etc/selinux/config add

if [ "$SELINUX" == "disabled" ]; then
    exit 0
fi

so that it doesn't bother if selinux is disabled.

But if selinux is enabled, it will send huge files by e-mail every day
until you relabel the entire filesystem.  This is particularly
difficult to do if you want to keep multiple systems installed on the
same box, such that you can chroot from the booted one to the other. 
This cron job means I can't keep these filesystems mounted at all,
because fixfiles is going to complain about them, and mounting them
with a context, such that fixfiles won't attempt to relabel them, will
prevent the chroot from functioning correctly.

Here's an idea to reduce the spam (just got a 270MB email, and that
still wasn't my big file server): have setfiles check *not* descend
into directories that are not labeled, or not labeled correctly. 
Since rebabeling them later would descend to components, there's no
real loss, and the email will be much smaller.

I changed fixfiles.cron to not send if SELinux is disabled.  And to
only send email with less then 100 lines.  Otherwise it sends you the
name of the file it saved the list in.  

You can mount the shares with a context mount and that will prevent
fixfiles from traversing them.

mount --context="system_u:object_r:mnt_t" /dev/abc /mnt/bigfiles

Err...  It didn't send anything with SELinux disabled.  Good idea on
limiting the file length.  A context mount would work for my home dir
mount points, but not for the chrooted image of earlier OS installs,
since when I install updates in the chroot, I'd rather have them
installed with the correct contexts.  IIUC, mounting them with a fixed
context would prevent this.

Looks like the code to omit the report from the e-mail is not working.
 I just got a 600MB e-mail aafter an everything install with selinux
enabled with the targeted policy.

AFAICT, mounting the filesystem with a context mount specified won't
work, because I have files in this filesystem that need proper
contexts.  The idea is that I have this filesystem containing all of
the data I don't want overwritten across installs (or shared by
multiple installs), such as home dirs, squid and mail spool, etc.  I
do --bind mounts to get say /var/spool/squid to map to what used to be
/l/squid (and I have to adjust /etc/squid/squid.conf to use
/var/spool/squid/ again; /l/squid won't work any more, even if it's
labeled correctly; not even if /var/spool/squid is the pathname in the
conf file and it's a soft link).

I really want to keep everything in a single filesystem.  I don't mind
the bind mounts much, but I still don't see how this would avoid the
huge messages that this cron job is going to spam me with.  How often
is it going to do this?  I wouldn't mind too much if it was only once
after install, but if it's going to do it daily or weekly, or even
monthly, I and probably most other users are going to need a
reasonable way to tell setfiles to not look in certain directories,
because they're labeled properly for another pathname.

FWIW, I've come up with the following work-around for the issues I
have.  The shell script code below is appended to /etc/selinux/config,
such that it affects the set of filesystems /sbin/fixfiles attempts to
check/relabel/etc.  I realize it's probably far too ugly and inclusive
for general use, but I thought others might like to use some work
around until we actually support some better means to specify which
filesystems to not check.  A regular expression set in this config
file might be a fine solution.

case ${FILESYSTEMSRW+set} in
set)
  FILESYSTEMSRW=`for dir in $FILESYSTEMSRW;
    do
      case $dir in
      /l | /l/* | /mnt/* | /media/* ) ;;
      *) echo $dir;;
      esac
    done
  ` ;;
esac

It has just occurred to me that the contents of the big e-mails I was
getting wasn't entirely clear.  Although the code to omit the report
and send an empty e-mail with the location of the file holding the
report is working, the output of the cron job still includes the
complete output of setfiles check, sent to stdout or stderr, and
that's the big e-mails I was getting.  Presumably redirecting the
outputs of fixfiles to /dev/null would fix that, but maybe -l
/dev/null should already do that but is failing to have the right effect.

policycoreutils-1_17_5-3
Will only display to stdout if log file is not specified.

Can this be done only if there are any *new* files with bad contexts?

I don't care about SELinux on some of my test machines, yet they still
spam me every day with an empty e-mail referencing a 130K file in
/var/tmp.  And this is just a default install.