Certain named builds improperly check writability of some directories when -u is used
BIND 9.12 introduced mandatory checks for writability of certain directories. Certain build types perform some of these checks in incorrect order when
-u is used.
Here is what happens for non-threaded Linux builds with support for capabilities:
nameddrops capabilities to the initial set,
managed-keys-directoryare checked for writability,
This means the checks in step 2 are made with the root user's privileges, albeit severely diminished by the limited capabilities which are in effect after step 1 (namely,
CAP_DAC_OVERRIDE is no longer set). So if e.g.
directory is set to a path which is writable by the user specified with
-u, but not for the root user (stripped of its superuser privileges),
named will (wrongly) refuse to start.
These same checks are differently broken for non-threaded Linux builds without support for capabilities and all builds on other platforms because step 1 above is never executed. This means that writability checks from step 2 always succeed, because they are performed with full superuser privileges rather than
-u user's privileges.
The only type of build where the problem does not exist are threaded Linux builds, because in their case,
setuid() is called between steps 1 and 2 above.
Fixing the problem likely requires moving the directory checks from the view configuration routines until after the last possible call to
named_os_changeuser(), similarly to how the current working directory is checked.