|
Red Hat Bugzilla – Full Text Bug Listing |
| Summary: | Port named to use libcap library | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nicolas Mailhot <nicolas.mailhot> |
| Component: | bind | Assignee: | Adam Tkac <atkac> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | 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 10:28:28 EST | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | ||
| Bug Depends On: | |||
| Bug Blocks: | 235706 | ||
|
Description
Nicolas Mailhot
2008-02-16 06:25:57 EST
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 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? *** 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)
[FAILED]
[root@workstation0 sysconfig]#
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. 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 http://marc.info/?l=bind-workers&r=1&b=200802&w=2 |