Description of problem: Likely related to https://bugzilla.redhat.com/show_bug.cgi?id=436895 I'm not sure rsyslog is the proper package to file this bug under, as I just 'cp' System.map from my Linux source directory to /boot, and adding a restorecon just after that could work around the issue. However, here it goes... SELinux denies access to rsyslog for home-compiled kernel System.map file which is generated as unconfined_u:object_r:boot_t:s0 instead of system_u:object_r:system_map_t:s0 Version-Release number of selected component (if applicable): [asuardi@sandman ~]$ rpm -qa | egrep 'syslog|selinux' | sort libselinux-2.0.64-2.fc9.i386 libselinux-devel-2.0.64-2.fc9.i386 libselinux-python-2.0.64-2.fc9.i386 rsyslog-3.14.1-2.fc9.i386 selinux-policy-3.3.1-55.fc9.noarch selinux-policy-targeted-3.3.1-55.fc9.noarch How reproducible: 100% Steps to Reproduce: 1. build a home-compiled kernel (eg. 2.6.26-rc5-git2 from kernel.org) 2. copy relevant files in /boot 3. wait for rsyslogd to restart Actual results: Jun 8 04:17:27 sandman kernel: imklog 3.14.1, log source = /proc/kmsg started. Jun 8 04:17:27 sandman kernel: Cannot find map file. Jun 8 04:17:27 sandman kernel: No module symbols loaded - kernel modules not enabled. Jun 8 04:17:27 sandman kernel: cannot find any symbols, turning off symbol lookups Jun 8 04:17:27 sandman rsyslogd: [origin software="rsyslogd" swVersion="3.14.1" x-pid="1477" x-info="http://www.rsyslog.com"] restart Jun 8 04:17:27 sandman setroubleshoot: SELinux is preventing rsyslogd (syslogd_t) "read" to ./System.map-2.6.26-rc5 (boot_t). For complete SELinux messages. run sealert -l f8269dbd-0c66-41be-bfa9-ad99552f6226 [root@sandman ~]# sealert -l f8269dbd-0c66-41be-bfa9-ad99552f6226 Summary: SELinux is preventing rsyslogd (syslogd_t) "read" to ./System.map-2.6.26-rc5 (boot_t). [...] Expected results: files copied in /boot have the proper context, and rsyslogd can read them Additional info: Here's how the System.map files appear: [root@sandman ~]# ls -lZ /boot/System.map-2.6.2* -rw-r--r-- root root system_u:object_r:system_map_t:s0 /boot/System.map-2.6.25.4-30.fc9.i686 -rw-r--r-- root root unconfined_u:object_r:boot_t:s0 /boot/System.map-2.6.26-rc5 -rw-r--r-- root root unconfined_u:object_r:boot_t:s0 /boot/System.map-2.6.26-rc5-git2 (Fedora 9 default one is okay, custom-compiled ones aren't) [root@sandman ~]# restorecon -v /boot/System.map-2.6.26-rc5-git2 restorecon reset /boot/System.map-2.6.26-rc5-git2 context unconfined_u:object_r:boot_t:s0->system_u:object_r:system_map_t:s0 (restorecon -v fixes it)
hmm, I really have no clue how to fix this. A plain copy creates the new file following the default behaviour based on the domain of the creating process (cp) and the type of the target directory. Creating a package for your custom kernel might help. Lets ask Daniel if there is some common practise in this.
If you copy to a directory which has multiple context residing in it, you need to reset the context your self. There is no easy way for the system to do this. I believe cp/restorecon is the best solution. You could theoretically use restorecond, if this was a common occurrence. You need to think of this the same way you think of DAC, in that you need to make sure the permissions are ok on the file.