Bind crashes on startup with the following in the system log: Sep 3 08:03:38 vespa named[3044]: starting BIND 9.5.0a6 -u named -t /var/named/ chroot Sep 3 08:03:38 vespa named[3044]: found 2 CPUs, using 2 worker threads Sep 3 08:03:38 vespa named[3044]: SDB ldap zone database module loaded. Sep 3 08:03:38 vespa named[3044]: SDB postgreSQL DB zone database module loaded . Sep 3 08:03:38 vespa named[3044]: SDB sqlite3 DB zone database module loaded. Sep 3 08:03:38 vespa named[3044]: SDB directory DB zone database module loaded. Sep 3 08:03:38 vespa named[3044]: loading configuration from '/etc/named.conf' Sep 3 08:03:38 vespa named[3044]: listening on IPv4 interface lo, 127.0.0.1#53 Sep 3 08:03:38 vespa named[3044]: listening on IPv4 interface eth0, 192.168.100 .110#53 Sep 3 08:03:38 vespa named[3044]: listening on IPv4 interface eth0:1, 172.27.27 .5#53 Sep 3 08:03:38 vespa named[3044]: listening on IPv4 interface tun0, 10.32.4.33# 53 Sep 3 08:03:38 vespa kernel: named[3045]: segfault at 0000000000000000 rip 0000 2aaaaafd8e80 rsp 00000000409fef80 error 4 The crash doesn't happen when SELinux is not enforcing or when the named process is not run in its confined domain. I'm running named in the chroot environment. (bind-9.5.0-11.a6.fc8.x86_64)
Created attachment 185141 [details] My config file
So bind now seems to bind to port 7011 for some reason and it is denied by SELinux: avc: denied { name_bind } for comm="named" egid=25 euid=25 exe="/usr/sbin/named" exit=-13 fsgid=25 fsuid=25 gid=25 items=0 pid=1002 scontext=system_u:system_r:named_t:s0 sgid=25 src=7011 subj=system_u:system_r:named_t:s0 suid=25 tclass=udp_socket tcontext=system_u:object_r:port_t:s0 tty=(none) uid=25 Bind should fail gracefully in this situation and not crash!
Created attachment 187361 [details] Full backtrace of all threads Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1094719824 (LWP 12643)] 0x00002aaaaafd90b0 in dns_resolver_createdispatchpool (res=0x2aaaaab21010, ndisps=8, tick=900) at resolver.c:7459 7459 if (res->dispatchv4pool[i] != NULL) Full backtrace in attachment.
Created attachment 187471 [details] This should fix it This patch should fix it - unverified.
Thanks for patch, makes sence. Will be fixed in 9.5.0-12.a6