Hide Forgot
Summary: SELinux is preventing /usr/sbin/named "write" access on log. Detailed Description: SELinux denied access requested by named. It is not expected that this access is required by named and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context unconfined_u:system_r:named_t:s0 Target Context unconfined_u:object_r:device_t:s0 Target Objects log [ sock_file ] Source named Source Path /usr/sbin/named Port <Unknown> Host (removed) Source RPM Packages bind-9.7.0-9.P1.fc13 Target RPM Packages Policy RPM selinux-policy-3.7.19-21.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.33.4-95.fc13.i686 #1 SMP Thu May 13 05:55:24 UTC 2010 i686 i686 Alert Count 2 First Seen Tue 01 Jun 2010 01:35:30 PM PDT Last Seen Tue 01 Jun 2010 01:39:25 PM PDT Local ID 021066c0-635a-4d5e-b7c8-2c7158e528f0 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1275424765.966:41941): avc: denied { write } for pid=26062 comm="named" name="log" dev=devtmpfs ino=1534170 scontext=unconfined_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:device_t:s0 tclass=sock_file node=(removed) type=SYSCALL msg=audit(1275424765.966:41941): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfe9b4dc a2=c51ff4 a3=ffffffc8 items=0 ppid=26061 pid=26062 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="named" exe="/usr/sbin/named" subj=unconfined_u:system_r:named_t:s0 key=(null) Hash String generated from catchall,named,named_t,device_t,sock_file,write audit2allow suggests: #============= named_t ============== allow named_t device_t:sock_file write;
There looks like something is wrong with the labeling on your machine? Or were you doing something with mock? /dev/log should not be labeled device_t
*** Bug 599128 has been marked as a duplicate of this bug. ***
Hi Daniel, I'm not doing anything with mock -- at least I have no such knowledge; if something else on my machine is misbehaving, then I can't explain it. This is a quite recent fresh installation, so there should be no labeling "mistakes'. The only "re-labeling" I have done would involve rdnc.key and getting DNS and DHCP to share access to authentication and security keys. This would be restricted to /etc/dhcp* /etc/named* and /var/named/... And I haven't added or modified any of the default labeling policy. So, as you can tell, I am playing in the near vicinity, but I don't think I have done anything with "log" and I'm not sure I understand what SELinux means by "log"... Hang on... I frequently read /var/log/messages with vim. If I were to accidently write out /var/log/messages as root, would that change it's labeling such that the above error would happen? Chris.
No. If you ran syslogd by hand this could happen. What does ls -lZ /dev/log show ls -lZ /dev/log srw-rw-rw-. root root system_u:object_r:devlog_t:s0 /dev/log