Description of problem:
After the installation the file /var/log/yum.log has wrong selinux context
[root@dell-pe6950-01 ~]# ls -Z /var/log/yum.log
-rw-r--r--. root root system_u:object_r:var_log_t:s0 /var/log/yum.log
[root@dell-pe6950-01 ~]# matchpathcon /var/log/yum.log
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install fresh RHEL6 system
This being created by anaconda?
Do we need to do something?
Anaconda has a list of things to run restorecon on, this may need to be added there.
Ahh, at a guess this will affect everything that got fixed by one of the installroot path fixes (so they are now in the correct place instead of /mnt/sysroot/*).
I think that should be just /var/lib/yum/* and /var/log/yum.log ... but don't hold me to that list :)
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.
** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
How was this system installed? Was it a minimal install? Desktop? Or ?
After doing a minimal install I have no /var/log/yum.log file and the context of /var/lib/yum/* is all correct. If I run yum update on the new system it creates /var/log/yum.log with the correct context.
I tried few more installations and I can confirm your results. The original system was installed in Beaker therefore I expect the issue is probably caused by Beaker environment. I think we can close this bug, sorry for confusion.
> After doing a minimal install I have no /var/log/yum.log file and the
> context of /var/lib/yum/* is all correct. If I run yum update on the
> new system it creates /var/log/yum.log with the correct context.
I can confirm this. But even with the "Standard server" installation I didn't
get any /var/log/yum.log file.