Bug 126388 - Daemon refuses to start due to linuxcaps disabled
Daemon refuses to start due to linuxcaps disabled
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Jason Vas Dias
: EasyFix
: 126939 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-20 22:27 EDT by Brian Bruns
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version: 9.2.3-18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-07-28 14:02:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brian Bruns 2004-06-20 22:27:34 EDT
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
Comment 1 Josh Rollyson 2004-06-20 22:39:24 EDT
I consider this is a security-related bug, the build option results in
unneeded privledges (root) being required, thus giving an increased
security risk.
Comment 2 Daniel Walsh 2004-06-23 17:43:24 EDT
Why is named see your kernel as prior to 2.4?

Dan
Comment 3 Brian Bruns 2004-06-23 17:59:31 EDT
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.
Comment 4 Josh Rollyson 2004-06-23 23:04:10 EDT
--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.

Comment 5 Enrico Scholz 2004-06-24 10:04:01 EDT
'--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.
Comment 6 Jason Vas Dias 2004-07-28 13:53:29 EDT
*** Bug 126939 has been marked as a duplicate of this bug. ***
Comment 7 Jason Vas Dias 2004-07-28 14:01:51 EDT
--disable-linux-caps was removed in bind-9.2.3-18
(use current version: bind-9.2.4rc6-3 +).

Note You need to log in before you can comment on or make changes to this bug.