Bug 433102

Summary: Port named to use libcap library
Product: [Fedora] Fedora Reporter: Nicolas Mailhot <nicolas.mailhot>
Component: bindAssignee: Adam Tkac <atkac>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: atkac, hduston, kasal, kernel-maint, mcepl, mcepl, mgalgoci, ovasik
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-20 15:28:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 235706    

Description Nicolas Mailhot 2008-02-16 11:25:57 UTC
As noted in http://thread.gmane.org/gmane.linux.kernel/635219 recent kernels
require an up-to-date libcap for various apps to work 

(for example named is currently dead as a dodo in rawhide following the last
kernel update:
named: capset failed: Operation not permitted: please ensure that the capset
kernel module is loaded.  see insmod(8))

Please update to the latest version at 
http://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/

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

kernel-2.6.25-0.40.rc1.git2.fc9.x86_64
bind-32:9.5.0-26.b2.fc9.x86_64
libcap-1.10-33.fc9.x86_64

How reproducible:
Always

Steps to Reproduce:
Try to start the named service

Comment 1 Chuck Ebbert 2008-02-16 15:46:34 UTC
According to that thread the message is just a warning and the app should still work

Comment 2 Nicolas Mailhot 2008-02-16 18:10:21 UTC
It's plenty fatal enough, sorry

Comment 3 Adam Tkac 2008-02-18 12:21:16 UTC
(In reply to comment #1)
> According to that thread the message is just a warning and the app should
still work

Hm, named doesn't use libcap for such syscall so it doesn't matter which version
is installed. It simply calls raw kernel interface (syscall(SYS_capset,
&caphead, &cap)). But when I changed (in /usr/include/linux/capability.h)

#define _LINUX_CAPABILITY_VERSION    _LINUX_CAPABILITY_VERSION_2
#define _LINUX_CAPABILITY_U32S       _LINUX_CAPABILITY_U32S_2

to

#define _LINUX_CAPABILITY_VERSION    _LINUX_CAPABILITY_VERSION_1
#define _LINUX_CAPABILITY_U32S       _LINUX_CAPABILITY_U32S_1

named works as expected. I'm not sure if this change will breaks other apps but
I think capability version 2 needs libcap version 2 (not sure, kernel people
will help with answer). Kernel crew could also try explain me why this syscall
is successful

capset(0x19980330, 0,
{CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
0}) = 0

but this is not

capset(0x20071026, 0,
{CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,
0}) = -1 EPERM (Operation not permitted)

Where is main difference?

Comment 4 Adam Tkac 2008-02-18 12:22:36 UTC
*** Bug 433075 has been marked as a duplicate of this bug. ***

Comment 5 Hal Duston 2008-02-18 16:45:42 UTC
The difference is as follows:
0x19980303 is _LINUX_CAPABILITY_VERSION_1, and
0x20071025 is _LINUX_CAPABILITY_VERSION_2.
Among the choices for getting bind working again are these:
1. Update bind to use libcap, and then libcap will handle any current and/or future version compatibility issues.
2. Compile bind against a set of 2.6.24 kernel headers, since I'd guess that 2.6.25 is where the capability version was bumped.
3. Patch bind to hardcode _LINUX_CAPABILITY_VERSION_1, since it is already hardcoding the rest of the system call.
   This would be in bin/named/unix/os.c#162
It doesn't seem likely that updating to the newer version of libcap would gain anything for bind with any of these choices.

Comment 6 Matthew Galgoci 2008-02-19 04:15:26 UTC
It's pretty fatal for named

[root@workstation0 sysconfig]# service named start
Starting named: named: capset failed: Operation not permitted: please ensure
that the capset kernel module is loaded.  see insmod(8)
                                                           [FAILED]
[root@workstation0 sysconfig]# 


Comment 7 Adam Tkac 2008-02-19 10:54:32 UTC
Use libcap is the best and long term solution. I'm going to prepare patch,
temporary fixed in bind-9.5.0-27.b2.fc9 which is build without threads and linux
capabilities.

Comment 8 Adam Tkac 2008-02-20 13:14:54 UTC
libcap 2.06 hits rawhide, reassigning to bind component + owner

Comment 9 Adam Tkac 2008-02-20 15:28:28 UTC
bind 9.5.0-28.b2 uses libcap and works fine on all kernels with both 1 and 2
libcap versions. Information about patch is on
http://marc.info/?l=bind-workers&r=1&b=200802&w=2