Bug 1559230

Summary:	file '/etc/ld.so.cache' relabelled to 'system_u:object_r:etc_t:s0'
Product:	[Fedora] Fedora	Reporter:	Ryan <stealthcipher>
Component:	selinux-policy-targeted	Assignee:	Lukas Vrabec <lvrabec>
Status:	CLOSED DUPLICATE	QA Contact:	Ben Levenson <benl>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	27	CC:	dwalsh
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-03-24 18:50:24 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ryan 2018-03-22 02:53:26 UTC

Description of problem:
I am frequently getting selinux alerts that /etc/ld.so.cache is unable to be accessed by system processes. Examination of the logs seems to point to auditd running at the same time it occurs. I run restorecon -v /etc/ld.so.cache and the file is relabelled to the correct context 'system_u:object_r:ld_so_cache_t:s0' but I have to do this every hour or so (seems to be some builtin systemd timer or cron job or something)

Version-Release number of selected component (if applicable):
selinux-policy-targeted.noarch-3.13.1-283.28.fc27
audit.x86_64 2.8.3-1.fc27

How reproducible:
very

Steps to Reproduce:
1. run fedora for a few hours, wait for the selinux alerts

Actual results:
file relabelled

Expected results:
file not relabelled

Additional info:
This bug may be more applicable to the audit component than selinux, but I am not fully sure that auditd is what is doing it although it does show the selinux alerts in the audit.log as well...

Comment 1 Lukas Vrabec 2018-03-24 18:50:24 UTC


*** This bug has been marked as a duplicate of bug 1543153 ***