Description of problem: "restorecon" should not have to change the type portion of the security context. Version-Release number of selected component (if applicable): TP2 RC9 How reproducible: Believe 100% Steps to Reproduce: 1. Install RHCI 2. Log in to run launch-fusor-installer 3. restorecon -RFvv / Actual results: Type portion of security context changes for some files Expected results: No type portion changes Additional info: Edited List: * restorecon reset /dev/shm/pulse-shm-* context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:user_tmpfs_t:s0 * restorecon reset /run/user/0/gvfs context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:fusefs_t:s0 * restorecon reset /run/user/0/keyring-<string> context unconfined_u:object_r:user_tmp_t:s0->system_u:object_r:gkeyringd_tmp_t:s0 (and contents) * restorecon reset /run/rubygem-passenger/passenger.1.0.20480 context system_u:object_r:passenger_var_run_t:s0->system_u:object_r:var_run_t:s0 (and contents) * restorecon reset /etc/grub.d/00_tuned context system_u:object_r:usr_t:s0->system_u:object_r:etc_t:s0 * restorecon reset /etc/foreman context system_u:object_r:etc_t:s0->system_u:object_r:foreman_config_t:s0 (and contents) * restorecon reset /root/.config context system_u:object_r:admin_home_t:s0->system_u:object_r:config_home_t:s0 (and contents) * restorecon reset /root/.Xauthority context unconfined_u:object_r:admin_home_t:s0->system_u:object_r:xauth_home_t:s0 * restorecon reset /usr/share/foreman/config/hooks context system_u:object_r:bin_t:s0->system_u:object_r:foreman_hook_t:s0
/root/.config and /root/.Xauthority appear to be GNOME configuration files. I'm unclear why they have the wrong context. The *corrected* file contexts match the policy in the system
Per QCI devs, switching to Sat 6
This is a bug in RHEL (SELinux tools) as we use context aliases. We can't do much about it. Asking Mirek to confirm.
(In reply to Lukas Zapletal from comment #8) > This is a bug in RHEL (SELinux tools) as we use context aliases. We can't do > much about it. Asking Mirek to confirm. Could you elaborate it more?
You told me the oher day that if there's an alias defined, restorecon might restore the context incorrectly. And that's what I suppose is happening right here. Anyway I was wrong, this is not the case, sorry and ignore. Thom, I am unable to reproduce this in Satellite 6.3. Fresh install: restorecon -RFvv /etc /usr/share/foreman restorecon reset /etc/yum/pluginconf.d/langpacks.conf context system_u:object_r:etc_runtime_t:s0->system_u:object_r:etc_t:s0 restorecon reset /etc/mail/virtusertable.db context system_u:object_r:etc_mail_t:s0->system_u:object_r:etc_aliases_t:s0 restorecon reset /etc/mail/access.db context system_u:object_r:etc_mail_t:s0->system_u:object_r:etc_aliases_t:s0 restorecon reset /etc/mail/domaintable.db context system_u:object_r:etc_mail_t:s0->system_u:object_r:etc_aliases_t:s0 restorecon reset /etc/mail/mailertable.db context system_u:object_r:etc_mail_t:s0->system_u:object_r:etc_aliases_t:s0 restorecon reset /etc/mail/aliasesdb-stamp context system_u:object_r:etc_mail_t:s0->system_u:object_r:etc_aliases_t:s0 restorecon reset /etc/selinux/strict/active context system_u:object_r:semanage_store_t:s0->system_u:object_r:selinux_config_t:s0 restorecon reset /etc/selinux/strict/active/modules context system_u:object_r:semanage_store_t:s0->system_u:object_r:selinux_config_t:s0 restorecon reset /etc/chrony.conf.orig context system_u:object_r:etc_runtime_t:s0->system_u:object_r:etc_t:s0 restorecon reset /etc/beah_beaker.conf.default context system_u:object_r:etc_runtime_t:s0->system_u:object_r:etc_t:s0 restorecon reset /etc/beah.conf.default context system_u:object_r:etc_runtime_t:s0->system_u:object_r:etc_t:s0 All files are labelled fine. Please provide Satellite 6 reproducer or talk to RHCI devs to fix your policy if you changed something.
lzap: Seems reasonable to me. Since this was opened so long ago and things have changed dramatically with QCI, closing as currentrelease. Will reopen with reproducer or open a new case if this reoccurs.