Created attachment 790096 [details] screenshot of my vm in openstack After running fedup to upgrade a VM from Fedora 19 to Fedora 20, I see some AVC but I only have secreen shot of it. It seems to be related to ldconfig and the directory used by dracut However, the system boot fine.
Interesting I suspect it is the %postrans script (new-kernel-pkg/rpm_script_t) running a file with type initrc_exec_t and transitioning to initrc_t, that process seems to run a dracut related command which seems to create /vat/tmp/dracut*, and then later runs ldconfig which does stuff inside the dracut dir. Might be this: /sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --update 3.11.9-200.fc19.x86_64 || exit $? Wondering whether it would be worth trying to figure out what init script it may be, I don't have anything that seems related inside my /etc/rc.d/init.d Wondering if it even makes sense to for initrc_t to transition to ldconfig_t I guess there are a few options: 1. just allow this as is 2. remove the transition from initrc_t to ldconfig_t 3. figure out which init script the kernel package %posttrans runs exactly and see whats going on in there
I think we have two issues here. Labeling issue and pipe issue. What does # rpm -q kernel --scripts Do you have s-c-kdump installed? Also try to run # fixfiles check to see mislabeled files.
I no longer have the vm, but I can try to get it. But since fedup is running in a mode with selinux being permissive, so that's likely not a big issue. I think I didn't have s-c-kdump installed, that was just a default install.
I'm having a similar problem as well, on two machines now; it's *quite* severe. Let me know if it's not the *same* problem and I'll open a new bug. Note that, as usual, my systems have unconfined disabled. To give you sense of scale: root@stodi# sudo restorecon -Rv /usr/bin/ restorecon reset /usr/bin/screen context staff_u:object_r:bin_t:s0->staff_u:object_r:screen_exec_t:s0 restorecon reset /usr/bin/zsh context staff_u:object_r:bin_t:s0->staff_u:object_r:shell_exec_t:s0 restorecon reset /usr/bin/ksu context staff_u:object_r:bin_t:s0->staff_u:object_r:su_exec_t:s0 restorecon reset /usr/bin/traceroute context staff_u:object_r:bin_t:s0->staff_u:object_r:traceroute_exec_t:s0 restorecon reset /usr/bin/tmux context staff_u:object_r:bin_t:s0->staff_u:object_r:screen_exec_t:s0 restorecon reset /usr/bin/stunnel context staff_u:object_r:bin_t:s0->staff_u:object_r:stunnel_exec_t:s0 restorecon reset /usr/bin/dash context staff_u:object_r:bin_t:s0->staff_u:object_r:shell_exec_t:s0 restorecon reset /usr/bin/irssi context staff_u:object_r:bin_t:s0->staff_u:object_r:irc_exec_t:s0 restorecon reset /usr/bin/teamd context system_u:object_r:bin_t:s0->system_u:object_r:NetworkManager_exec_t:s0 restorecon reset /usr/bin/start-puppet-agent context system_u:object_r:bin_t:s0->system_u:object_r:puppetagent_exec_t:s0 restorecon reset /usr/bin/nmap context staff_u:object_r:bin_t:s0->staff_u:object_r:traceroute_exec_t:s0 restorecon reset /usr/bin/newrole context staff_u:object_r:bin_t:s0->staff_u:object_r:newrole_exec_t:s0 restorecon reset /usr/bin/start-puppet-master context system_u:object_r:bin_t:s0->system_u:object_r:puppetmaster_exec_t:s0 restorecon reset /usr/bin/mandb context staff_u:object_r:bin_t:s0->staff_u:object_r:mandb_exec_t:s0 root@stodi# I had to setenforce 0 to get *anything* done. Including sudo, which when attempted resulted in this: sudo: PERM_SUDOERS: setresuid(-1, 1, -1): Operation not permitted Output of the rpm -q thing: http://paste.fedoraproject.org/106239/40161104 I have no GUI, so no s-c-kdump Besides those listed above, here's the rest of what fixfiles said: http://paste.fedoraproject.org/106241/61377714 (that's assuming the " Warning no default label" things are un-interesting; the *full* file is at https://gist.githubusercontent.com/rlpowell/71ebc0ac52d86407174d/raw/fixfiles.txt )
Today I discovered that sshd can't startup because: type=AVC msg=audit(06/01/2014 11:59:47.297:204864) : avc: denied { getattr } for pid=4825 comm=sshd-keygen path=/etc/ssh/ssh_host_rsa_key dev=vda2 ino=263395 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:sshd_key_t:s0 tclass=file In response and out of desperation I tried: sudo yum reinstall '*selinux*' I had previously tried sudo yum reinstall selinux-policy The list of packages this time was: Installed: libselinux.x86_64 0:2.2.1-6.fc20 libselinux-python.x86_64 0:2.2.1-6.fc20 libselinux-ruby.x86_64 0:2.2.1-6.fc20 libselinux-utils.x86_64 0:2.2.1-6.fc20 selinux-policy.noarch 0:3.12.1-166.fc20 selinux-policy-devel.noarch 0:3.12.1-166.fc20 selinux-policy-doc.noarch 0:3.12.1-166.fc20 selinux-policy-targeted.noarch 0:3.12.1-166.fc20 And now it's fine. So, yay?, and maybe that's the workaround?, but still a pretty unfortunate upgrade situation.
selinux-policy-targeted package is the one you had to reinstall. Not sure why it was not working on an upgrade.
Yes, an upgrade issue. Lets close this bug for now to see if we get more issues like this.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days