From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031016 K-Meleon/0.8.2 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): bind-9.2.3-16 How reproducible: Always 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 [FAILED] Expected Results: BIND named daemon should start answering queries Additional info: Kernel is custom 2.6.6 with exec-shield and DoS patch glibc-2.3.3-32
I consider this is a security-related bug, the build option results in unneeded privledges (root) being required, thus giving an increased security risk.
Why is named see your kernel as prior to 2.4? Dan
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 be needed. 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 doesn't). 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 +).