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:
-
named
drops capabilities to the initial set, -
directory
and potentiallymanaged-keys-directory
are checked for writability, -
setuid()
is called.
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.