Bug 174920 - named fails when booted with "capability.disable=1"
named fails when booted with "capability.disable=1"
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2005-12-04 01:57 EST by JW
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-05 18:57:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description JW 2005-12-04 01:57:34 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; MSIE 6.0; Windows; U; AIIEEEE!; Win98; Windows 98; en-US; Gecko masquerading as IE; should it matter?; rv:1.8b) Gecko/20050217

Description of problem:
If you boot kernel with "capability.disable=1" then named fails because it wrongly checks the result value from syscall(SYS_capset,...).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.boot linux with boot-time option "capcbility.disable=1"
2.start named

Actual Results:  named exits with message "capset failed: : please ensure that the capset kernel module is loaded: see insmod()"
And this doesn't even get written out via syslog(), even though named is running as a daemon, which doesn't help anybody find out what on earch has gone wrong.

Expected Results:  Named should run normally.
It shouldn't really concern named as to what the return value of the capset() syscall is - it could log it via syslog as a warning, but it shouldnt fail because it is perfectly reasonable for named to continue. Especially when somebody decides to deliberately disable the LSM backdoor-friendly kernel hooks.

Additional info:
Comment 1 Jason Vas Dias 2005-12-05 14:14:51 EST
We don't support booting the kernel or running named under a kernel booted with 
Named needs to set capabilities and should not run if it fails to do so.

Because this error could happen before named has set up its log facilities,
the error will not be logged to syslog, but will be emitted to stderr and
the initscript should fail .
Comment 2 JW 2005-12-05 17:49:47 EST
(In reply to comment #1)
> We don't support booting the kernel or running named under a kernel booted with 
>    capability.disable=1

Then maybe you should take that parameter out of the capability module.
Why do you have boot setting which aren't "supported"?

Comment 3 Jason Vas Dias 2005-12-05 18:57:55 EST
The kernel supports many options that are not meant for normal production

There are many packages other than named that use capabilities and setcap .

Named relies on setcap to acquire the capabilities it needs to run, and does
not support running with capabilities support disabled in the kernel.


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