Too much privilege required for a simple syntax checking via named-checkconf
Summary
Was using the named-checkconf
with '-p -x' options to do a simple syntax checking of the named.conf
configuration file with the -t <chroot_dir>
option ... as a non-root user.
All is well until a fix to actually use chroot()
function call got introduced.
Now, all my unit tests broke because root UID 0 (and/or CAP_SYS_CHROOT
capability) is required to properly execute chroot()
. It's rather uncomfortable to do unit testing at elevated privilege.
How about when just the -p
option is supplied, that we NOT call chroot()
function?
BIND version used
9.16.22-Debian
Steps to reproduce
mkdir -p test/etc/bind
vim test/etc/bind/named.conf
Create an empty option clause in test/etc/bind/named.conf
using options {};
Execute:
$ named-checkconf -p -x -t test /etc/bind/named.conf
isc_dir_chroot: permission denied
What is the current bug behavior?
Function chroot()
is being evoked during basic syntax checking.
What is the expected correct behavior?
To perform syntax checking using a change relative directory. And not having to be requiring a CAP_SYS_CHROOT
capabilitiy at user-level.
Relevant configuration files
test/etc/bind/named.conf
options {};
Relevant logs and/or screenshots
commit e502b133 Author: Mark Andrews marka@isc.org Date: Mon Feb 16 02:01:16 2009 +0000
Possible fixes
In bin/check/named-checkconf.c
In the argument switch-case t
option, relocate that body of code to just outside the while/switch-case, replace body of code a simple chroot = 1;
and
At the end of the arg parameter while/switch-case, relocate the following to something like:
if (chroot) {
if (print) {
/* insert CWD/change-PWD code snippet here */
} else {
result = isc_dir_chroot(isc_commandline_argument);
if (result != ISC_R_SUCCESS) {
fprintf(stderr, "isc_dir_chroot: %s\n",
isc_result_totext(result));
exit(1);
}
}
}