Summary: | net-dns/bind-9.4.2, named fails to start with USE=threads | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Graham Murray <graham> |
Component: | Current packages | Assignee: | Konstantin Arkhipov (RETIRED) <voxus> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | Adrian.Bassett, atoth, bind+disabled, conikost, dennis.freise, dliana, eva, ezotrank, jochen+gentoo-bugs, micmicsh, public.avatar, rob |
Priority: | High | ||
Version: | 2008.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Kernel Configuration |
Description
Graham Murray
2008-05-03 21:33:06 UTC
(In reply to comment #0) > After upgrading from net-dns-bind-9.4.1_p1, named failed to start with the > error message "Starting named: named: capset failed: Operation not permitted: > please ensure that the capset kernel module is loaded. see insmod(8)". Version > 9.4.1_p1 worked fine with the same USE flags. There is a warning about threads > and a vserver environment, so even though I am not using a vserver environment > I disabled the threads USE flag and then named started correctly. you have the capability module available (or directly built into your kernel)? Same here - SECURITY_CAPABILITIES is set to "=y" in .config (by GRSEC), kernel = hardened-sources-2.6.24-r1 Created attachment 151787 [details]
Kernel Configuration
I think that I have enabled all of the capability options. grepping the kernel source I cannot see any indication of a module called 'capset'
emerge -1 sys-libs/libcap Sorry I'll be don't right. USE="-threads" emerge -av net-dns/bind && emerge -1 sys-libs/libcap You might be interested in this thread of the linux kernel mailing list: http://www.gossamer-threads.com/lists/linux/kernel/875073 As it seems libcap needs an update.. (In reply to comment #6) > You might be interested in this thread of the linux kernel mailing list: > > http://www.gossamer-threads.com/lists/linux/kernel/875073 > > As it seems libcap needs an update.. > This indicates an upgrade to libcap-2.05 but it is failing for me using libcap-2.08-r1 (In reply to comment #6) > You might be interested in this thread of the linux kernel mailing list: > > http://www.gossamer-threads.com/lists/linux/kernel/875073 > > As it seems libcap needs an update.. > ldd `which named` | grep cap The problem arose after the upgrade linux-headers-2.6.25. Bind and squid stopped working. If compile bind with linux-headers-2.6.24 - everything works. By analogy of how this issue decided by squid, i`m made little patch, solves this problem with bind-9.4.2. Compile and work fine with USE="threads" and linux-headers-2.6.25-r3 diff -Nuar bind-9.4.2.orig/bin/named/unix/os.c bind-9.4.2/bin/named/unix/os.c --- bind-9.4.2.orig/bin/named/unix/os.c 2006-02-04 01:51:38.000000000 +0200 +++ bind-9.4.2/bin/named/unix/os.c 2008-06-03 10:21:56.000000000 +0300 @@ -159,7 +159,11 @@ return; memset(&caphead, 0, sizeof(caphead)); +#ifdef _LINUX_CAPABILITY_VERSION_1 + caphead.version = _LINUX_CAPABILITY_VERSION_1; +#else caphead.version = _LINUX_CAPABILITY_VERSION; +#endif caphead.pid = 0; memset(&cap, 0, sizeof(cap)); cap.effective = caps; (In reply to comment #9) Thank you! This works fine here :) Now i can compile with threads! I would have an purpose maybe ;) What about using _LINUX_CAPABILITY_VERSION_3 and libcap 2.10? This works also, but fixes the nasty warning: warning: `named' uses 32-bit capabilities (legacy support in use) The only thing is, that we need >=sys-libs/libcap-2.10 for it... Conrad Kostecki is right. i modified the ebuild and the patch, compilation was smooth. named started, no warning messages in dmesg, normal operation for some hours. # diff -Nuar /usr/portage/net-dns/bind/bind-9.5.0_p1-r2.ebuild /usr/portage/local/blackbit/net-dns/bind/bind-9.5.0_p1-r2.ebuild --- /usr/portage/net-dns/bind/bind-9.5.0_p1-r2.ebuild 2008-07-27 10:56:35.000000000 +0200 +++ /usr/portage/local/blackbit/net-dns/bind/bind-9.5.0_p1-r2.ebuild 2008-08-01 17:16:09.809471034 +0200 @@ -26,7 +26,8 @@ RDEPEND="${DEPEND} selinux? ( sec-policy/selinux-bind ) - resolvconf? ( || ( net-dns/openresolv net-dns/resolvconf-gentoo ) )" + resolvconf? ( || ( net-dns/openresolv net-dns/resolvconf-gentoo ) ) + threads? ( >=sys-libs/libcap-2.1.0 )" S="${WORKDIR}/${PN}-${MY_PV}" @@ -57,6 +58,8 @@ "${i}" done + use threads && epatch "${FILESDIR}"/${PN}-9.5.0-libcap.patch + use dlz && epatch "${FILESDIR}"/${PN}-9.4.0-dlzbdb-close_cursor.patch # bind fails to reconnect to MySQL5 databases, bug #180720, patch by Nicolas Brousse # # cat /usr/portage/local/blackbit/net-dns/bind/files/bind-9.5.0-libcap.patch --- bin/named/unix/os.c 2008-08-01 15:20:07.401472392 +0200 +++ bin/named/unix/os.c 2008-08-01 15:24:13.941474019 +0200 @@ -170,7 +170,11 @@ return; #ifndef HAVE_LIBCAP memset(&caphead, 0, sizeof(caphead)); +#ifdef _LINUX_CAPABILITY_VERSION_3 + caphead.version = _LINUX_CAPABILITY_VERSION_3; +#else caphead.version = _LINUX_CAPABILITY_VERSION; +#endif caphead.pid = 0; memset(&cap, 0, sizeof(cap)); cap.effective = caps; # bind-9.5.0_p2 does not seem to correct this problem. i was able to build and start 9.5.0_p2 with a unmodified ebuild or adding the patch. some time later i got in the log [kernel] warning: `named' uses deprecated v2 capabilities in a way that may be insecure. since it was linked to libcap (there is no dependency for it in the ebuild!) i could no more start bind after unmerging libcap. was 9.5.0_p1 linked to libcap too? i guess so, but cannot check easily because the ebuild was removed from the tree. building 9.5.0_p2 without libcap is possible, but it does not start with well known "Starting named: named: capset failed: Operation not permitted: please ensure that the capset kernel module is loaded. see insmod(8)" the ebuild modification and dependency for libcap >=2.10 seems to work best. normal operation and no warnings. the file to which the patch is applied was not changed, so the patch can be used unchanged. This should be fixed in =bind-9.4.2_p2-r1 and =bind-9.5.0_p2-r1. Please test and reopen this bug if necessary. (In reply to comment #14) > This should be fixed in =bind-9.4.2_p2-r1 and =bind-9.5.0_p2-r1. Please test > and reopen this bug if necessary. > I just can't understand after reading this post, how a version of bind wothout the patch and the dependency could go stable??? |