GitLab

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);
        }
    }
}