Bug #44537 for bind9-public: [PATCH] Support of WKS records under chroot

Hello. I mentioned this 11/14/2016 on bind-workers list but did not receive any feedback. I am looking for good way to support symbolic service names for WKS records under chroot. Such record can be similar to:  IN WKS 127.0.0.1 UDP (ipp sunrpc dhcpc) in a zone. It is ok when loading the zone usually, but it usually fails when named is running under chroot (-t parameter). It fill fail on current Fedora and RHEL 7. These records are parsed in lib/dns/rdata/in_1/wks_11.c and calls getprotobyname and getservbyname are used to convert symbolic names to numbers when loading the zone. Those calls need /etc/nsswitch.conf and depending on configuration /etc/protocols, /etc/services. Libc library will try to dlopen /lib/libnss_files.so.2 but will fail from chroot. Of course I can copy that library into chroot directory. But then I risk it will not be maintained by system updates if I did one-time copy. If I bind it using mount --bind, it is much worse. I put executable into chroot, that in case of modification is used by many privileged executables in the system. If BIND was made somehow to modify that library, attacker would be able to get code executed outside of chroot and only write permissions to library stops him. I think it is against the idea of chroot. I would like to avoid the need to copy libraries into chroot. If I try to use these service calls before chroot, libnss library will be loaded correctly. It would still need data files /etc/protocols and /etc/services, but executables are out of reach. I have really simple patch for this. I doubt a bit if it is ok to ignore error if getting value fails. But that is value not configured by administrator or used anyway. It is used only to load the library. That is attachment 0001. It solves the issue somehow. Other than ignoring an error, there might be problem if NSS library was configured to access something other than plain files. I do not think it makes much sense on a server, but you can have configured services backend via LDAP backend. Then there is a risk it would not start named only because LDAP service did not work at the moment. Or slow start of it significantly down. Or it might write an error. I have wrote some proof of concept moving basic handling from wks specific to net.c. Then you could use it as parameter on startup of named-checkconf or named. Advantage is only those who may need it can enable preloading of services & protocols before chroot. However I doubt again what should be done in case of error? Not running named? Printing error and continuing? Ignoring it completely seems wrong to me , if I requested it. If I print an error, I should be able to specify protocol and server tested. But that makes it more complicated without added value. Fast and dirty code I made for that is in attachment 0002. I ask for an advice and opinion. What way seems to be cleanest to you? How would you solve it? What variant would you prefer upstream? Is there a reason why it is left to chroot creators? Best Regards, Petr Menšík -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@redhat.com  PGP: 65C6C973

---