Bug 127313 - /etc/cron.daily/fixfiles.cron leaving large files in /var/tmp
/etc/cron.daily/fixfiles.cron leaving large files in /var/tmp
Product: Fedora
Classification: Fedora
Component: policycoreutils (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2004-07-06 11:25 EDT by John Ellson
Modified: 2007-11-30 17:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-24 11:46:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Ellson 2004-07-06 11:25:39 EDT
Description of problem:
/etc/cron.daily/fixfiles.cron is leaving large (~40MByte) files in
/var/tmp each time it runs.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. look in /var/tmp after fixfile.cron has been running for a few days
Actual results:
Multiple 40M+ files left in /var/tmp

Expected results:
Script needs to clean up, or use /var/log 

Additional info:
Comment 1 G.Wolfe Woodbury 2004-07-09 04:01:48 EDT
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

so that it doesn't bother if selinux is disabled.
Comment 2 Alexandre Oliva 2004-07-09 17:33:55 EDT
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.
Comment 3 Alexandre Oliva 2004-07-10 15:35:19 EDT
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.
Comment 4 Daniel Walsh 2004-07-20 11:22:09 EDT
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
Comment 5 Alexandre Oliva 2004-07-21 01:13:24 EDT
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.
Comment 6 Alexandre Oliva 2004-09-05 02:58:21 EDT
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.
Comment 7 Alexandre Oliva 2004-09-05 03:37:37 EDT
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
      case $dir in
      /l | /l/* | /mnt/* | /media/* ) ;;
      *) echo $dir;;
  ` ;;
Comment 8 Alexandre Oliva 2004-09-14 23:05:51 EDT
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.
Comment 9 Daniel Walsh 2004-09-21 15:19:35 EDT
Will only display to stdout if log file is not specified.
Comment 10 Joe Orton 2004-09-27 05:11:44 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.