Description of problem: restorecond is spamming /var/log/messages with the following messages: Jan 30 18:23:21 senfl restorecond: Will not restore a file with more than one ha rd link (/root/.history.LOCK) No such file or directory Jan 30 18:23:28 senfl restorecond: Will not restore a file with more than one ha rd link (/root/.history.LOCK) No such file or directory Jan 30 18:26:18 senfl restorecond: Will not restore a file with more than one ha rd link (/root/.history.LOCK) No such file or directory Jan 30 18:26:24 senfl restorecond: Will not restore a file with more than one ha rd link (/root/.history.LOCK) No such file or directory Jan 30 18:26:29 senfl restorecond: Will not restore a file with more than one ha rd link (/root/.history.LOCK) No such file or directory Jan 30 18:26:41 senfl restorecond: Will not restore a file with more than one ha rd link (/root/.history.LOCK) No such file or directory and so on ad infinitum. Version-Release number of selected component (if applicable): selinux-policy-3.5.13-40.fc10.noarch selinux-policy-targeted-3.5.13-40.fc10.noarch policycoreutils-2.0.57-14.fc10.x86_64 Note that I have set root's default shell to /bin/zsh. Random theory: maybe in the process of updating the ~/.history file, zsh is temporarily creating a hardlink to .history.LOCK that restorecond notices and tries to relabel? If so, this file is temporary, because I never managed to see it with "ls -a". Incidentally, I have a stock /etc/selinux/restorecond.conf that seems to direct restorecond to monitor all files under every user's home directory. I didn't immediately see any way to exclude /root/.history.LOCK. # cat /etc/selinux/restorecond.conf /etc/services /etc/resolv.conf /etc/samba/secrets.tdb /etc/mtab /var/run/utmp /var/log/wtmp ~/* ~/.mozilla/plugins/libflashplayer.so
I now notice that I'm also occasionally getting similar error messages about other files as well, under some conditions: Jan 30 19:12:30 senfl restorecond: Will not restore a file with more than one ha rd link (/home/daw/.calendar~) No such file or directory ... Jan 30 19:14:36 senfl restorecond: Will not restore a file with more than one ha rd link (/root/.xauthURiITZ-c) No such file or directory Jan 30 19:14:36 senfl restorecond: Will not restore a file with more than one ha rd link (/root/.xauthURiITZ-l) No such file or directory Jan 30 19:14:36 senfl restorecond: Will not restore a file with more than one ha rd link (/root/.history.LOCK) No such file or directory Jan 30 19:16:04 senfl restorecond: Will not restore a file with more than one ha rd link (/home/daw/.history.LOCK) No such file or directory I'm guessing these were triggered when I logged in and started a new Gnome session (which started up several programs, including ical, a calendar app) and perhaps when I used "su - root" or "ssh root@localhost". However I have not rigorously verified this.
Fixed in policycoreutils-2.0.57-16
Thanks for the fix! Any tips on how to test policycoreutils-2.0.57-16 on a F10 box? It's not in the default F10 repos. (The latest they have is 2.0.57-14.) It's not in the F10 *testing* repos. And if I enable the rawhide repos, it tries to get policycoreutils.x86_64 0:2.0.61-7.fc11, which pulls in policycoreutils-gui.x86_64 0:2.0.61-7.fc11, which requires python >= 2.6, which in turn requires upgrading dozens of packages, and the dependencies fail for several of these, so that's a no-go.
You can bang me on the head to put it into testing. Just added. Sorry about that.
Yup, I can confirm policycoreutils-2.0.57-16.fc10.x86_64 fixes this bug for me, without introducing any other ill effects. Thanks for the rapid fix, Daniel!
This is an old bugzilla but the same problem seems to have been reintroduced in F20. I'm seeing these.... Jan 31 07:39:49 meimei restorecond: Warning! /root/.xauthlpj2gn-l refers to a file with more than one hard link, not fixing hard links. Jan 31 07:39:49 meimei restorecond: (null) get context on /root/.xauthlpj2gn-n failed: 'No such file or directory' in my logs. Should a new bugzilla be opened or this one resurrected?
(In reply to Ed Greshko from comment #6) I can confirm this as well with selinux-policy-targeted.noarch 3.12.1-122.fc20
You probably no longer need to run restorecond in F20. Unless you have a particular file that keeps getting mislabeled.