Red Hat Bugzilla – Bug 433102
Port named to use libcap library
Last modified: 2013-04-30 19:38:44 EDT
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
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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Try to start the named service
According to that thread the message is just a warning and the app should still work
It's plenty fatal enough, sorry
(In reply to comment #1)
> According to that thread the message is just a warning and the app should
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
#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
0}) = 0
but this is not
0}) = -1 EPERM (Operation not permitted)
Where is main difference?
*** Bug 433075 has been marked as a duplicate of this bug. ***
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.
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)
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
libcap 2.06 hits rawhide, reassigning to bind component + owner
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