Bug 127313
Summary: | /etc/cron.daily/fixfiles.cron leaving large files in /var/tmp | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | John Ellson <john.ellson> |
Component: | policycoreutils | Assignee: | Daniel Walsh <dwalsh> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | dwalsh, jorton, oliva, pgraner, redwolfe |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-11-24 16:46:04 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
John Ellson
2004-07-06 15:25:39 UTC
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. |