Red Hat Bugzilla – Bug 126388
Daemon refuses to start due to linuxcaps disabled
Last modified: 2007-11-30 17:10:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5)
Description of problem:
Latest bind rpm from development is compiled with
--disable-linux-caps, thus preventing bind from running on machines
when the -u flag is used during startup.
Confirmed that older -13 version works fine, and is not compiled with
--disable-linux-caps. Recompiling -16 on the server did not help.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install bind-9.2.3-16 rpms
2. /etc/rc.d/init.d/named start
Actual Results: Starting named: named: -u not supported on Linux
kernels older than 2.3.99-pre3 or 2.2.18 when using threads
Expected Results: BIND named daemon should start answering queries
Kernel is custom 2.6.6 with exec-shield and DoS patch
I consider this is a security-related bug, the build option results in
unneeded privledges (root) being required, thus giving an increased
Why is named see your kernel as prior to 2.4?
Thats a good question.
[root@everest linux]# uname -a
Linux everest.sosdg.org 2.6.6-sosdg2-execshield #4 Mon Jun 14 12:54:31
EST 2004 i686 athlon i386 GNU/Linux
Kernel is a stock 2.6.6 kernel with the DoS fix, MPPE/MPPC patches for
PPPd, squashfs, and exec-shield. I can attach the .config should it
I've done tests with the older -13 version, which starts fine with no
issues, even recompiled the older -13 against our installed header
files, and still worked fine.
Testing with the -16 rpm from the Fedora archives, it fails with the
error I gave above, even after I recompile -16 against the headers we
have on our system (which are abiet not the standard ones from
glibc-kernheaders, but that doesn't explain why -13 works and -16
Removing --disable-linux-caps from -16 and recompiling allows it to
run though, without a problem.
Looking more into this, its most likely a bug in BIND, but I'm not
sure entirely, as debugging issues was never one of my strong points.
What do you need from me in order to better diagnose the problem? I
can provide access via ssh to the box in question if necessary.
--disable-linux-caps shouldn't be needed - except for some obscure
debugging situations, it will be detected correctly.
Without linux caps, BIND can't keep the ability to bind to privledged
ports when it drops root privledge, and consequently, it refuses to
run as a non-root user in this situation.
The problem is twofold:
1) The error message is wrong. If --disable-linux-caps has been used
and the version is later than the versions in the error message, the
message should state that BIND has been compiled without the required
compile time options to be able to drop root privledges. Apparently
--disable-linux-caps tweaks the same #ifdef's as the version
detection. This is an upstream problem.
2) There is *no* reason to use --disable-linux-caps on a normal
production system. Without heavy kernel modification, any kernel
version later than the ones in that error message will work fine
without that option. This is a specfile problem, but I'd go so far as
to suggest that it be reported to the upstream so that they can
consider ripping out the configure option or renaming it.
'--disable-linux-caps' is needed for
* SELinux systems without linux-capabilities LSM; capset() will fail
with -ENOSYS in this case
* systems without CAP_SYS_RESOURCE; typical vservers are an example
I agree that the error-message is misleading and an upstream bug.
*** Bug 126939 has been marked as a duplicate of this bug. ***
--disable-linux-caps was removed in bind-9.2.3-18
(use current version: bind-9.2.4rc6-3 +).