| Summary: | unable to uninstall old kernels due to scriptlet errors | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Julian Sikorski <belegdol> |
| Component: | selinux-policy-targeted | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED ERRATA | QA Contact: | Ben Levenson <benl> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | bcl, dwalsh, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mads, mgrepl, pjones |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | selinux-policy-3.10.0-55.fc16 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-11-10 17:29:42 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Julian Sikorski
2011-11-02 17:50:30 UTC
This is what I found in /var/log/messages: Nov 2 18:36:18 snowball2 yum[4699]: Erased: 1:kmod-nvidia-3.1.0-0.rc10.git0.1.fc16.x86_64-285.05.09-1.fc16.1.x86_64 Nov 2 18:36:18 snowball2 kernel: [ 6239.798203] type=1401 audit(1320255378.926:4): security_compute_sid: invalid context unconfined_u:unconfined_r:depmod_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:rpm_script_t:s0-s0:c0.c1023 tcontext=system_u:object_r:depmod_exec_t:s0 tclass=process Nov 2 18:36:19 snowball2 yum[4699]: Erased: 1:kmod-nvidia-3.1.0-1.fc16.x86_64-285.05.09-1.fc16.2.x86_64 Nov 2 18:36:19 snowball2 kernel: [ 6240.192469] type=1401 audit(1320255379.321:5): security_compute_sid: invalid context unconfined_u:unconfined_r:depmod_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:rpm_script_t:s0-s0:c0.c1023 tcontext=system_u:object_r:depmod_exec_t:s0 tclass=process Nov 2 18:36:19 snowball2 kernel: [ 6240.496549] type=1401 audit(1320255379.625:6): security_compute_sid: invalid context unconfined_u:unconfined_r:bootloader_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:rpm_script_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bootloader_exec_t:s0 tclass=process Nov 2 18:36:19 snowball2 kernel: [ 6240.546532] type=1401 audit(1320255379.675:7): security_compute_sid: invalid context unconfined_u:unconfined_r:bootloader_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:rpm_script_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bootloader_exec_t:s0 tclass=process Nov 2 18:36:23 snowball2 yum[4699]: Erased: kernel-devel Nov 2 18:36:23 snowball2 yum[4699]: kernel-devel: ts_done name in te is kernel should be kernel-devel Nov 2 18:36:29 snowball2 yum[4699]: Erased: kernel-devel Nov 2 18:36:29 snowball2 yum[4699]: kernel-devel: ts_done name in te is kernel should be kernel-devel this is probably a problem with kmod-nvidia vs selinux. I'll run a full relabel and see if it goes away. yum -y update to get latest selinux-policy restorecon -R -v /sbin # ls -lZ /sbin/new-kernel-pkg -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /sbin/new-kernel-pkg Make sure it looks like this, There was a labeling problem where this file as labeled bootloader_exec_t. I needed to update to selinux-policy-3.10.0-51.fc16.noarch from testing to fix this problem. Console is still not error-free though: Test transakcji został ukończony powodzeniem Wykonywanie transakcji Usuwanie : kernel.x86_64 1/2 /sbin/new-kernel-pkg: line 277: /sbin/grubby: Brak dostępu /sbin/new-kernel-pkg: line 284: /sbin/grubby: Brak dostępu Usuwanie : kernel.x86_64 2/2 /sbin/new-kernel-pkg: line 277: /sbin/grubby: Brak dostępu /sbin/new-kernel-pkg: line 284: /sbin/grubby: Brak dostępu Again sorry for Polish. The errors say /sbin/grubby: Access denied. I ran package-cleanup via sudo, and there are no denials in the log. To add more info, old kernels are still in /boot/grub2/grub.cfg even though the kernel rpms are gone. Can you run "/sbin/grubby --help"? Have you done a full relabeling? How? Do "yum reinstall grubby" make any difference? $ sudo /sbin/grubby --help
[sudo] password for julas:
Usage: grubby [OPTION...]
--add-kernel=kernel-path add an entry for the specified kernel
--add-multiboot=STRING add an entry for the specified multiboot kernel
--args=args default arguments for the new kernel or new arguments for kernel being updated
--mbargs=STRING default arguments for the new multiboot kernel or new arguments for multiboot kernel being
updated
--bad-image-okay don't sanity check images in boot entries (for testing only)
--boot-filesystem=bootfs filestystem which contains /boot directory (for testing only)
--bootloader-probe check if lilo is installed on lilo.conf boot sector
-c, --config-file=path path to grub config file to update ("-" for stdin)
--copy-default use the default boot entry as a template for the new entry being added; if the default is not
a linux image, or if the kernel referenced by the default image does not exist, the first
linux entry whose kernel does exist is used as the template
--default-kernel display the path of the default kernel
--elilo configure elilo bootloader
--extlinux configure extlinux bootloader (from syslinux)
--grub configure grub bootloader
--grub2 configure grub2 bootloader
--info=kernel-path display boot information for specified kernel
--initrd=initrd-path initrd image for the new kernel
-i, --extra-initrd=initrd-path auxilliary initrd image for things other than the new kernel
--lilo configure lilo bootloader
--make-default make the newly added entry the default boot entry
-o, --output-file=path path to output updated config file ("-" for stdout)
--remove-args=STRING remove kernel arguments
--remove-mbargs=STRING remove multiboot kernel arguments
--remove-kernel=kernel-path remove all entries for the specified kernel
--remove-multiboot=STRING remove all entries for the specified multiboot kernel
--set-default=kernel-path make the first entry referencing the specified kernel the default
--silo configure silo bootloader
--title=entry-title title to use for the new kernel entry
--update-kernel=kernel-path updated information for the specified kernel
-v, --version print the version of this program and exit
--yaboot configure yaboot bootloader
--zipl configure zipl bootloader
Help options:
-?, --help Show this help message
--usage Display brief usage message
I have actually done a full relabeling (which I mentioned in comment 3) by activating it in system-config-selinux. The label on /sbin/grubby is as follows:
$ ls -lZ /sbin/grubby
-rwxr-xr-x. root root system_u:object_r:bootloader_exec_t:s0 /sbin/grubby
rpm -V grubby shows no issues.
Dan, I assume /usr/bin/package-cleanup should be system_u:object_r:rpm_exec_t:s0 too? Yes good point. Fixed in selinux-policy-3.10.0-54.fc16 Looking at the changelog, it seems like the fix did not make it into this build: http://koji.fedoraproject.org/koji/buildinfo?buildID=272301 /me starts thinking: How about /usr/bin/debuginfo-install and /usr/bin/yum-builddep ? These issues have apparently not been noticed in other ways, so it seems to me like access to rpm_var_lib_t is less restricted than it should be? Well you are running as unconfined_t most likely so it would not be a problem. Only time this ends up in a problem is if a rpm runs post install scripts. I would like to retract comment 11 - the fix is in there, this problem is really fixed in selinux-policy-3.10.0-54.fc16. selinux-policy-3.10.0-55.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-55.fc16 selinux-policy-3.10.0-55.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |