Bug 174920 - named fails when booted with "capability.disable=1"
Summary: named fails when booted with "capability.disable=1"
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: bind
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-12-04 06:57 UTC by JW
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-12-05 23:57:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description JW 2005-12-04 06:57:34 UTC
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):
bind-9.3.1-14_FC4

How reproducible:
Always

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

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 19:14:51 UTC
We don't support booting the kernel or running named under a kernel booted with 
   capability.disable=1
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 22:49:47 UTC
(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 23:57:55 UTC
The kernel supports many options that are not meant for normal production
operation.

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.