Bug 450418 - rsyslog fails to read custom kernel System.map file due to SELinux
rsyslog fails to read custom kernel System.map file due to SELinux
Product: Fedora
Classification: Fedora
Component: rsyslog (Show other bugs)
i686 Linux
low Severity low
: ---
: ---
Assigned To: Peter Vrabec
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-06-07 22:46 EDT by Alessandro Suardi
Modified: 2008-06-14 07:32 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-06-14 07:32:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alessandro Suardi 2008-06-07 22:46:00 EDT
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


 instead of


Version-Release number of selected component (if applicable):

[asuardi@sandman ~]$ rpm -qa | egrep 'syslog|selinux' | sort

How reproducible:


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
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


SELinux is preventing rsyslogd (syslogd_t) "read" to ./System.map-2.6.26-rc5


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
-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 

(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

(restorecon -v fixes it)
Comment 1 Peter Vrabec 2008-06-13 04:36:14 EDT
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.

Comment 2 Daniel Walsh 2008-06-14 07:32:57 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.