Hide Forgot
Sep 20 20:08:17 srv-rhsoft named[988479]: ../../../lib/dns/openssl_link.c:294: fatal error: Sep 20 20:08:17 srv-rhsoft named[988479]: OpenSSL pseudorandom number generator cannot be initialized (see the `PRNG not seeded' message in the OpenSSL FAQ) Sep 20 20:08:17 srv-rhsoft named[988479]: exiting (due to fatal error in library) who the hell does such invasive obviously not proper tested changes in minor updates? -------------------- https://gitlab.isc.org/isc-projects/bind9/commit/24172bd2eeba91441ab1c65d2717b0692309244a random-device "/dev/urandom"; can't work because the chroot don't contain /dev/urandom at all at is obviously broken for years [root@srv-rhsoft:~]$ ls /var/named/chroot/dev/ insgesamt 0 crw-r--r-- 1 root named 1, 3 2009-08-21 15:03 null crw-r--r-- 1 root named 1, 8 2009-08-21 15:03 random crw-r--r-- 1 root named 1, 5 2009-08-21 15:03 zero [root@srv-rhsoft:~]$ rpm -q --file /var/named/chroot/dev/random bind-chroot-9.11.4-5.P1.fc28.x86_64 -------------------- and that really (besides urandom is missing) makes it magically to a working random device? don't look so dev_chroot_prep() { dev_create random c 1 8 dev_create zero c 1 5 dev_create null c 1 3 } dev_create() { DEVNAME="$ROOTDIR/dev/$1" shift if ! [ -e "$DEVNAME" ]; then /bin/mknod -m 0664 "$DEVNAME" $@ /bin/chgrp named "$DEVNAME" if [ -x /usr/sbin/selinuxenabled -a -x /sbin/restorecon ]; then /usr/sbin/selinuxenabled && /sbin/restorecon "$DEVNAME" > /dev/null || : fi fi }
Hi Harald, is not probably broken for years. I think it is broken for about 4 days. I broke it by backporting commit [1] in minor version. Yes, I admit it was not tested properly in chroot environment. If you could find a time to write an automated test, I would appreciate pull request. I can see it would find the issue much sooner that way. 1. https://src.fedoraproject.org/rpms/bind/c/6e9104cae5059bffde95f6dac831b0d57720d430?branch=master
bind-9.11.4-9.P2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f22b937f52
bind-9.11.4-9.P2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-a54e46032f
bind-9.11.4-9.P2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-a54e46032f
bind-9.11.4-9.P2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f22b937f52
bind-9.11.4-10.P2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f22b937f52
bind-9.11.4-10.P2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-a54e46032f
chroot still looks fishy but at least bind-32:9.11.4-10.P2.fc28.x86_64 continues to work [root@srv-rhsoft:~]$ ls /var/named/chroot/dev/ insgesamt 0 crw-r--r-- 1 root named 1, 3 2009-08-21 15:03 null crw-r--r-- 1 root named 1, 8 2009-08-21 15:03 random crw-r--r-- 1 root named 1, 5 2009-08-21 15:03 zero [root@srv-rhsoft:~]$ systemctl status named ● named.service - DNS Server Loaded: loaded (/etc/systemd/system/named.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2018-09-27 13:25:18 CEST; 36s ago Process: 953822 ExecStopPost=/usr/libexec/setup-named-chroot.sh /var/named/chroot off /etc/named-chroot.files (code=exited, status=0/SUCCESS) Process: 953821 ExecStop=/usr/bin/kill -TERM $MAINPID (code=exited, status=0/SUCCESS) Process: 953902 ExecStartPre=/usr/sbin/named-checkconf -t /var/named/chroot -z /etc/named.conf (code=exited, status=0/SUCCESS) Process: 953863 ExecStartPre=/usr/libexec/setup-named-chroot.sh /var/named/chroot on /etc/named-chroot.files (code=exited, status=0/SUCCESS) Main PID: 953903 (named) Tasks: 11 (limit: 512) Memory: 75.2M CGroup: /system.slice/named.service └─953903 /usr/sbin/named -4 -f -u named -t /var/named/chroot Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: listening on IPv4 interface lo, 127.0.0.1#53 Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: listening on IPv4 interface vpn-server, 192.168.11.1#53 Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: listening on IPv4 interface vmnet8, 192.168.196.2#53 Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: listening on IPv4 interface br-wan, 62.178.103.85#53 Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: listening on IPv4 interface br-guest, 192.168.10.1#53 Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: listening on IPv4 interface br-lan, 192.168.2.2#53 Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: listening on IPv4 interface vpn-client, 10.0.0.241#53 Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: generating session key for dynamic DNS Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: sizing zone task pool based on 16 zones Sep 27 13:25:18 srv-rhsoft.rhsoft.net named[953903]: set up managed keys zone for view _default, file 'managed-keys.bind'
bind-9.11.4-10.P2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-a54e46032f
bind-9.11.4-10.P2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f22b937f52
The -10 release of the package appears to be still broken on F28. It gives SELinux denials and chrooted named refuses to start. Specifically: type=AVC msg=audit(1538083144.528:216): avc: denied { read } for pid=1762 comm="named" name="urandom" dev="dm-3" ino=1183207 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=chr_file permissive=1 type=AVC msg=audit(1538083144.528:217): avc: denied { open } for pid=1762 comm="named" path="/dev/urandom" dev="dm-3" ino=1183207 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=chr_file permissive=1 type=AVC msg=audit(1538083144.528:218): avc: denied { getattr } for pid=1762 comm="named" path="/dev/urandom" dev="dm-3" ino=1183207 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:named_conf_t:s0 tclass=chr_file permissive=1 Even after running restorecon, This is what I see in /var/named/chroot/dev: [root@beauty dev]# ls -lZ total 0 crw-rw-r--. 1 root named unconfined_u:object_r:null_device_t:s0 1, 3 Dec 4 2013 null crw-rw-r--. 1 root named unconfined_u:object_r:random_device_t:s0 1, 8 Dec 4 2013 random crw-rw-r--. 1 root named system_u:object_r:named_conf_t:s0 1, 9 Sep 28 07:07 urandom crw-rw-r--. 1 root named unconfined_u:object_r:zero_device_t:s0 1, 5 Dec 4 2013 zero I'm guessing that named_conf_t should probably be random_device_t, right?
Sorry, actually probably urandom_device_t. In fact, when I set it like this, it starts.
(In reply to Bojan Smojver from comment #11) > [root@beauty dev]# ls -lZ > total 0 > crw-rw-r--. 1 root named unconfined_u:object_r:null_device_t:s0 1, 3 Dec > 4 2013 null > crw-rw-r--. 1 root named unconfined_u:object_r:random_device_t:s0 1, 8 Dec > 4 2013 random > crw-rw-r--. 1 root named system_u:object_r:named_conf_t:s0 1, 9 Sep > 28 07:07 urandom > crw-rw-r--. 1 root named unconfined_u:object_r:zero_device_t:s0 1, 5 Dec > 4 2013 zero > > I'm guessing that named_conf_t should probably be random_device_t, right? Yes, it should. I completely forgot it requires modification of selinux-policy. I tested in only in my Fedora 28 container where restorecon does not work.
bind-9.11.4-10.P2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
Just it occured to me when testing on f28: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007fd1c60e75b9 in __GI_abort () at abort.c:79 #2 0x000055d1d3a7b705 in library_fatal_error (file=<optimized out>, line=294, format=0x7fd1ca2f83f0 "OpenSSL pseudorandom number generator cannot be initialized (see the `PRNG not seeded' message in the OpenSSL FAQ)", args=0x7ffd751aa230) at ../../../bin/named-sdb/main.c:277 #3 0x00007fd1c8efa106 in isc_error_fatal () from /lib64/libisc.so.169 #4 0x00007fd1ca2a83a6 in dst.openssl_init () from /lib64/libdns.so.1102 #5 0x00007fd1ca2ae997 in dst_lib_init2 () from /lib64/libdns.so.1102 #6 0x000055d1d3ab4249 in ns_server_create (mctx=0x55d1d5ba26f0, serverp=0x55d1d3d30d70 <ns_g_server>) at ../../../bin/named-sdb/server.c:8898 #7 0x000055d1d3a7c931 in setup () at ../../../bin/named-sdb/main.c:1342 #8 main (argc=<optimized out>, argv=<optimized out>) at ../../../bin/named-sdb/main.c:1554 It is kind tricky, because it would pass when there is enough entropy on that machine. If there is not, OpenSSL wants to get some entropy from /dev/urandom.
Until selinux-policy is adjusted properly, please use these commands: semanage fcontext -a -e /dev/urandom /var/named/chroot/dev/urandom semanage fcontext -a -e /dev/urandom /var/named/chroot_sdb/dev/urandom restorecon /var/named/chroot*/dev/urandom It should work after it fine.
bind-9.11.4-10.P2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
bind-9.11.4-10.P2.fc28.x86_64 - at least it satrts now somehow most of the time this is still a joke [root@srv-rhsoft:~]$ ls /var/named/chroot/dev/ insgesamt 0 crw-r--r-- 1 root named 1, 3 2009-08-21 15:03 null crw-r--r-- 1 root named 1, 8 2009-08-21 15:03 random crw-r--r-- 1 root named 1, 5 2009-08-21 15:03 zero but yesterday i still had the smae idiotic message but thank to "Restart=laways" it recovered after boot, maybe ordering after "rngd.service haveged.service" will prevent this now but the whole stuff is fishy [root@srv-rhsoft:~]$ cat /etc/systemd/system/named.service [Unit] Description=DNS Server After=network-online.target network-wan-bridge.service network-wlan-bridge.service openvpn.service rngd.service haveged.service Requires=network-online.target [Service] Type=simple ExecStartPre=/usr/libexec/setup-named-chroot.sh /var/named/chroot on /etc/named-chroot.files ExecStartPre=/usr/sbin/named-checkconf -t /var/named/chroot -z /etc/named.conf ExecStart=/usr/sbin/named -4 -f -u named -t /var/named/chroot ExecReload=/usr/bin/kill -HUP $MAINPID ExecStop=/usr/bin/kill -TERM $MAINPID ExecStopPost=/usr/libexec/setup-named-chroot.sh /var/named/chroot off /etc/named-chroot.files TimeoutSec=25 Restart=always RestartSec=1 CapabilityBoundingSet=CAP_CHOWN CAP_SETGID CAP_SETUID CAP_SYS_ADMIN CAP_DAC_READ_SEARCH CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW CAP_IPC_LOCK CAP_SYS_CHROOT MemoryDenyWriteExecute=yes NoNewPrivileges=yes PrivateDevices=yes PrivateTmp=yes ProtectControlGroups=yes ProtectKernelModules=yes ProtectKernelTunables=yes RestrictAddressFamilies=AF_INET AF_INET6 AF_LOCAL AF_UNIX AF_NETLINK RestrictRealtime=yes SystemCallArchitectures=x86-64 SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @obsolete @raw-io @reboot @swap acct modify_ldt add_key adjtimex clock_adjtime delete_module fanotify_init finit_module get_mempolicy init_module io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp kexec_load keyctl lookup_dcookie migrate_pages move_pages open_by_handle_at perf_event_open process_vm_readv process_vm_writev ptrace remap_file_pages request_key set_mempolicy swapoff swapon uselib vmsplice ReadOnlyPaths=/etc ReadOnlyPaths=/usr ReadOnlyPaths=/var/lib InaccessiblePaths=-/root InaccessiblePaths=-/media InaccessiblePaths=-/boot InaccessiblePaths=-/home InaccessiblePaths=-/run/console InaccessiblePaths=-/run/dbus InaccessiblePaths=-/run/lock InaccessiblePaths=-/run/mount InaccessiblePaths=-/run/systemd/generator InaccessiblePaths=-/run/systemd/system InaccessiblePaths=-/run/systemd/users InaccessiblePaths=-/run/udev InaccessiblePaths=-/run/user InaccessiblePaths=-/var/lib/dbus InaccessiblePaths=-/var/lib/rpm InaccessiblePaths=-/var/lib/systemd InaccessiblePaths=-/var/lib/dnf InaccessiblePaths=-/var/spool [Install] WantedBy=multi-user.target
This was working fine for me until bind-chroot-32:9.11.4-5.P1.fc28, then broke when updated to bind-chroot-32:9.11.4-10.P2.fc28. Logs from the service start: Oct 06 10:12:02 hostname named[6552]: starting BIND 9.11.4-P2-RedHat-9.11.4-10.P2.fc28 (Extended Support Version) <id:> Oct 06 10:12:02 hostname named[6552]: running on Linux x86_64 4.18.11-200.fc28.x86_64 #1 SMP Sun Sep 30 15:31:40 UTC 2> Oct 06 10:12:02 hostname named[6552]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '-> Oct 06 10:12:02 hostname named[6552]: running as: named -u named -c /etc/named.conf -t /var/named/chroot Oct 06 10:12:02 hostname named[6552]: compiled by GCC 8.1.1 20180712 (Red Hat 8.1.1-5) Oct 06 10:12:02 hostname named[6552]: compiled with OpenSSL version: OpenSSL 1.1.0i 14 Aug 2018 Oct 06 10:12:02 hostname named[6552]: linked to OpenSSL version: OpenSSL 1.1.0i-fips 14 Aug 2018 Oct 06 10:12:02 hostname named[6552]: compiled with libxml2 version: 2.9.8 Oct 06 10:12:02 hostname named[6552]: linked to libxml2 version: 20908 Oct 06 10:12:02 hostname named[6552]: compiled with zlib version: 1.2.11 Oct 06 10:12:02 hostname named[6552]: linked to zlib version: 1.2.11 Oct 06 10:12:02 hostname named[6552]: threads support is enabled Oct 06 10:12:02 hostname named[6552]: ---------------------------------------------------- Oct 06 10:12:02 hostname named[6552]: BIND 9 is maintained by Internet Systems Consortium, Oct 06 10:12:02 hostname named[6552]: Inc. (ISC), a non-profit 501(c)(3) public-benefit Oct 06 10:12:02 hostname named[6552]: corporation. Support and training for BIND 9 are Oct 06 10:12:02 hostname named[6552]: available at https://www.isc.org/support Oct 06 10:12:02 hostname named[6552]: ---------------------------------------------------- Oct 06 10:12:02 hostname named[6552]: adjusted limit on open files from 4096 to 1048576 Oct 06 10:12:02 hostname named[6552]: found 2 CPUs, using 2 worker threads Oct 06 10:12:02 hostname named[6552]: using 1 UDP listener per interface Oct 06 10:12:02 hostname named[6552]: using up to 21000 sockets Oct 06 10:12:02 hostname named[6552]: ../../../lib/dns/openssl_link.c:294: fatal error: Oct 06 10:12:02 hostname audit[6552]: ANOM_ABEND auid=4294967295 uid=25 gid=25 ses=4294967295 pid=6552 comm="named" ex> Oct 06 10:12:02 hostname named[6552]: OpenSSL pseudorandom number generator cannot be initialized (see the `PRNG not s> Oct 06 10:12:02 hostname named[6552]: exiting (due to fatal error in library) Oct 06 10:12:02 hostname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump> Oct 06 10:12:02 hostname systemd[1]: Started Process Core Dump (PID 6557/UID 0). Oct 06 10:12:03 hostname systemd[1]: named-chroot.service: Control process exited, code=exited status=1 Oct 06 10:12:03 hostname systemd[1]: named-chroot.service: Failed with result 'exit-code'. Oct 06 10:12:03 hostname systemd[1]: Failed to start Berkeley Internet Name Domain (DNS). Oct 06 10:12:03 hostname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=named-chroot com> Oct 06 10:12:03 hostname systemd[1]: Stopping Set-up/destroy chroot environment for named (DNS)... Oct 06 10:12:03 hostname systemd-coredump[6558]: Process 6552 (named) of user 25 dumped core. Stack trace of thread 6552: #0 0x00007ff1e747eeab raise (libc.so.6) #1 0x00007ff1e74695b9 abort (libc.so.6) #2 0x000055fd0b8a6605 library_fatal_error.cold.4 (named) #3 0x00007ff1e9053106 isc_error_fatal (libisc.so.169) #4 0x00007ff1ea4013a6 dst__openssl_init (libdns.so.1102) #5 0x00007ff1ea407997 dst_lib_init2 (libdns.so.1102) #6 0x000055fd0b8def59 ns_server_create (named) #7 0x000055fd0b8a76bd main (named) #8 0x00007ff1e746b11b __libc_start_main (libc.so.6) #9 0x000055fd0b8a801a _start (named) Stack trace of thread 6556: #0 0x00007ff1e754218f epoll_wait (libc.so.6) #1 0x00007ff1e908b06c watcher (libisc.so.169) #2 0x00007ff1e8787594 start_thread (libpthread.so.0) #3 0x00007ff1e7541e6f __clone (libc.so.6) Stack trace of thread 6554: #0 0x00007ff1e878d51c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.> #1 0x00007ff1e90736e5 run (libisc.so.169) #2 0x00007ff1e8787594 start_thread (libpthread.so.0) #3 0x00007ff1e7541e6f __clone (libc.so.6) Stack trace of thread 6553: #0 0x00007ff1e878d51c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.> #1 0x00007ff1e90736e5 run (libisc.so.169) #2 0x00007ff1e8787594 start_thread (libpthread.so.0) #3 0x00007ff1e7541e6f __clone (libc.so.6) Stack trace of thread 6555: #0 0x00007ff1e878d51c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.> #1 0x00007ff1e907a7a8 run (libisc.so.169) #2 0x00007ff1e8787594 start_thread (libpthread.so.0) #3 0x00007ff1e7541e6f __clone (libc.so.6) Downgraded back to the packages from https://koji.fedoraproject.org/koji/buildinfo?buildID=1135047 works again.
(In reply to Lucas Maneos from comment #19) > This was working fine for me until bind-chroot-32:9.11.4-5.P1.fc28, then > broke when updated to bind-chroot-32:9.11.4-10.P2.fc28. Logs from the > service start: > > > Oct 06 10:12:02 hostname named[6552]: starting BIND > 9.11.4-P2-RedHat-9.11.4-10.P2.fc28 (Extended Support Version) <id:> > Oct 06 10:12:02 hostname named[6552]: running on Linux x86_64 > 4.18.11-200.fc28.x86_64 #1 SMP Sun Sep 30 15:31:40 UTC 2> > Oct 06 10:12:02 hostname named[6552]: built with > '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '-> > Oct 06 10:12:02 hostname named[6552]: running as: named -u named -c > /etc/named.conf -t /var/named/chroot > Oct 06 10:12:02 hostname named[6552]: compiled by GCC 8.1.1 20180712 (Red > Hat 8.1.1-5) > Oct 06 10:12:02 hostname named[6552]: compiled with OpenSSL version: OpenSSL > 1.1.0i 14 Aug 2018 > Oct 06 10:12:02 hostname named[6552]: linked to OpenSSL version: OpenSSL > 1.1.0i-fips 14 Aug 2018 > Oct 06 10:12:02 hostname named[6552]: compiled with libxml2 version: 2.9.8 > Oct 06 10:12:02 hostname named[6552]: linked to libxml2 version: 20908 > Oct 06 10:12:02 hostname named[6552]: compiled with zlib version: 1.2.11 > Oct 06 10:12:02 hostname named[6552]: linked to zlib version: 1.2.11 > Oct 06 10:12:02 hostname named[6552]: threads support is enabled > Oct 06 10:12:02 hostname named[6552]: > ---------------------------------------------------- > Oct 06 10:12:02 hostname named[6552]: BIND 9 is maintained by Internet > Systems Consortium, > Oct 06 10:12:02 hostname named[6552]: Inc. (ISC), a non-profit 501(c)(3) > public-benefit > Oct 06 10:12:02 hostname named[6552]: corporation. Support and training for > BIND 9 are > Oct 06 10:12:02 hostname named[6552]: available at > https://www.isc.org/support > Oct 06 10:12:02 hostname named[6552]: > ---------------------------------------------------- > Oct 06 10:12:02 hostname named[6552]: adjusted limit on open files from 4096 > to 1048576 > Oct 06 10:12:02 hostname named[6552]: found 2 CPUs, using 2 worker threads > Oct 06 10:12:02 hostname named[6552]: using 1 UDP listener per interface > Oct 06 10:12:02 hostname named[6552]: using up to 21000 sockets > Oct 06 10:12:02 hostname named[6552]: ../../../lib/dns/openssl_link.c:294: > fatal error: > Oct 06 10:12:02 hostname audit[6552]: ANOM_ABEND auid=4294967295 uid=25 > gid=25 ses=4294967295 pid=6552 comm="named" ex> > Oct 06 10:12:02 hostname named[6552]: OpenSSL pseudorandom number generator > cannot be initialized (see the `PRNG not s> > Oct 06 10:12:02 hostname named[6552]: exiting (due to fatal error in library) > Oct 06 10:12:02 hostname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 > ses=4294967295 msg='unit=systemd-coredump> > Oct 06 10:12:02 hostname systemd[1]: Started Process Core Dump (PID 6557/UID > 0). > Oct 06 10:12:03 hostname systemd[1]: named-chroot.service: Control process > exited, code=exited status=1 > Oct 06 10:12:03 hostname systemd[1]: named-chroot.service: Failed with > result 'exit-code'. > Oct 06 10:12:03 hostname systemd[1]: Failed to start Berkeley Internet Name > Domain (DNS). > Oct 06 10:12:03 hostname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 > ses=4294967295 msg='unit=named-chroot com> > Oct 06 10:12:03 hostname systemd[1]: Stopping Set-up/destroy chroot > environment for named (DNS)... > Oct 06 10:12:03 hostname systemd-coredump[6558]: Process 6552 (named) of > user 25 dumped core. > > Stack trace of > thread 6552: > #0 > 0x00007ff1e747eeab raise (libc.so.6) > #1 > 0x00007ff1e74695b9 abort (libc.so.6) > #2 > 0x000055fd0b8a6605 library_fatal_error.cold.4 (named) > #3 > 0x00007ff1e9053106 isc_error_fatal (libisc.so.169) > #4 > 0x00007ff1ea4013a6 dst__openssl_init (libdns.so.1102) > #5 > 0x00007ff1ea407997 dst_lib_init2 (libdns.so.1102) > #6 > 0x000055fd0b8def59 ns_server_create (named) > #7 > 0x000055fd0b8a76bd main (named) > #8 > 0x00007ff1e746b11b __libc_start_main (libc.so.6) > #9 > 0x000055fd0b8a801a _start (named) > Have you applied selinux steps mentioned in comment #16? It should fix the issue in chroot.
(In reply to Harald Reindl from comment #18) > bind-9.11.4-10.P2.fc28.x86_64 - at least it satrts now somehow most of the > time > > this is still a joke > [root@srv-rhsoft:~]$ ls /var/named/chroot/dev/ > insgesamt 0 > crw-r--r-- 1 root named 1, 3 2009-08-21 15:03 null > crw-r--r-- 1 root named 1, 8 2009-08-21 15:03 random > crw-r--r-- 1 root named 1, 5 2009-08-21 15:03 zero > > but yesterday i still had the smae idiotic message but thank to > "Restart=laways" it recovered after boot, maybe ordering after "rngd.service > haveged.service" will prevent this now but the whole stuff is fishy > > It requires access to /dev/urandom to gather entropy. rngd should not hurt, but should not be required to even start. Did you restart named-chroot after installing bind-chroot-9.11.4-10.P2.fc28.x86_64 and importing custom policy from comment #16?
looks like the chroot-script needs a ton of capabilities and has a bad error handling so that you can find the messages somwhere long before named itelf will fail, CapabilityBoundingSet removed for now
(In reply to Harald Reindl from comment #22) > looks like the chroot-script needs a ton of capabilities and has a bad error > handling so that you can find the messages somwhere long before named itelf > will fail, CapabilityBoundingSet removed for now Capabilities are required when preparing chroot. Devices are now created on demand before start. That is main reason why it has its own named-chroot-setup.service. It requires capability for mount, mknod create and more. Just named itself should be restricted.
(In reply to Petr Menšík from comment #20) > Have you applied selinux steps mentioned in comment #16? It should fix the > issue in chroot. Yes (although I don't have a /var/named/chroot_sdb), and even tried with SELINUX disabled, same issue. Running it under strace shows EACCESS on trying to open /dev/{,u}random: # sestatus SELinux status: disabled # strace -f -e trace=file /usr/sbin/named -u named -t /var/named/chroot [...] chroot("/var/named/chroot") = 0 chdir("/") = 0 strace: Process 14668 attached strace: Process 14669 attached [pid 14668] openat(AT_FDCWD, "/proc/self/task/14669/comm", O_RDWR) = -1 ENOENT (No such file or directory) strace: Process 14670 attached [pid 14668] openat(AT_FDCWD, "/proc/self/task/14670/comm", O_RDWR) = -1 ENOENT (No such file or directory) strace: Process 14671 attached [pid 14668] openat(AT_FDCWD, "/proc/self/task/14671/comm", O_RDWR) = -1 ENOENT (No such file or directory) strace: Process 14672 attached [pid 14668] openat(AT_FDCWD, "/proc/self/task/14672/comm", O_RDWR) = -1 ENOENT (No such file or directory) [pid 14668] openat(AT_FDCWD, "/etc/pki/tls/openssl.cnf", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 14668] openat(AT_FDCWD, "/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = -1 EACCES (Permission denied) [pid 14668] openat(AT_FDCWD, "/dev/random", O_RDONLY|O_NOCTTY|O_NONBLOCK) = -1 EACCES (Permission denied) [pid 14668] openat(AT_FDCWD, "/dev/srandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or directory) [pid 14668] --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=14668, si_uid=25} --- [pid 14669] +++ killed by SIGABRT (core dumped) +++ [pid 14672] +++ killed by SIGABRT (core dumped) +++ [pid 14671] +++ killed by SIGABRT (core dumped) +++ [pid 14670] +++ killed by SIGABRT (core dumped) +++ [pid 14668] +++ killed by SIGABRT (core dumped) +++ --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_DUMPED, si_pid=14668, si_uid=25, si_status=SIGABRT, si_utime=0, si_stime=11} --- +++ exited with 1 +++ The chroot dev directory contents are: # ls -la /var/named/chroot/dev total 8 drwxr-x--- 2 root named 4096 Oct 28 07:40 . drwxr-x---. 7 root named 4096 Sep 26 21:16 .. crw-rw-r-- 1 root named 1, 3 Nov 23 2013 null crw-rw-r-- 1 root named 1, 8 Nov 23 2013 random crw-rw-r-- 1 root named 1, 9 Oct 28 07:40 urandom crw-rw-r-- 1 root named 1, 5 Nov 23 2013 zero
(In reply to Lucas Maneos from comment #24) > Running it under strace shows EACCESS on trying to open /dev/{,u}random: It turns out that this was due to /var being mounted with the nodev option. Earlier versions worked because they were falling back to the pre-chroot /dev/random: Oct 28 08:26:02 hostname named[27545]: could not open entropy source /dev/random: permission denied Oct 28 08:26:02 hostname named[27545]: using pre-chroot entropy source /dev/random Sorry for the noise.
Okay, original cause was resolved by updated selinux-policy package, no other modification should be necessary. Required selinux-policy is 3.14.2-39. I think it could be possible to work around that by: touch /var/named/chroot/dev/urandom then adding /dev/urandom to /etc/named-chroot.files This way original device is mounted, I think it should also work with nodev mount option to /var. It would work for any /dev file required. I will think whether this is good idea to have by default. I would not have to worry about setting correct selinux context, rights at the cost of more bind mounts. Empty files would have to be prepared for devices. It would rpm -V bind-chroot make fail verification either when running or when stopped, because type of file would be always different.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.