Hide Forgot
Description of problem: With SELinux enforcing, issuing a cobbler sync results in: ..snip... running: service dhcpd restart received on stdout: Shutting down dhcpd: [ OK ] Starting dhcpd: [ OK ] received on stderr: /etc/init.d/functions: line 19: /sbin/consoletype: Permission denied ..snip.. Putting SELinux into permissive prevents this from happening. Unfortunately nothing is reported in audit.log as far as I can tell. Version-Release number of selected component (if applicable): # rpm -qa | grep cobbler cobbler-2.4.0-1.el6.noarch # rpm -qa | grep selinux ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 libselinux-python-2.0.94-5.3.el6_4.1.x86_64 libselinux-2.0.94-5.3.el6_4.1.x86_64 selinux-policy-targeted-3.7.19-195.el6_4.18.noarch libselinux-ruby-2.0.94-5.3.el6_4.1.x86_64 libselinux-utils-2.0.94-5.3.el6_4.1.x86_64 selinux-policy-3.7.19-195.el6_4.18.noarch pki-selinux-9.0.3-30.el6.noarch How reproducible: Everytime Steps to Reproduce: 1. run cobbler sync 2. 3. Actual results: received on stderr: /etc/init.d/functions: line 19: /sbin/consoletype: Permission denied Expected results: No error Additional info:
Created attachment 833303 [details] Strace of cobbler sync strace -f -e write=1,2 cobbler sync 2>cobbler.strace output with SELinux in enforcing mode
We would need to see AVC msgs.
As I stated above, no AVC messages are seen in audit.log - this is why I attached the strace.
Does it work in permissive mode?
(In reply to Miroslav Grepl from comment #4) > Does it work in permissive mode? Yes, as I mentioned in the original report, switching to permissive (setenforce 0) makes everything work as it should, and the message "received on stderr: /etc/init.d/functions: line 19: /sbin/consoletype: Permission denied" is not displayed.
Could you try with dontaudit rules off. #semodule -DB Generate the AVCs Look for consoletype command and see if there are AVCs related. #semodule -B Will turn dontaudit rules back on.
Hm. Unfortunately I can no longer reproduce the problem. I notice the system has recently updated to selinux-policy-targeted-3.7.19-231.el6.noarch, so perhaps that addressed the issue somehow. I'll close this and re-open it if I see it again.