Re: [MERGE] Use libcap instead of direct linux capability syscalls
tis 2009-10-27 klockan 14:46 +1300 skrev Amos Jeffries: I would like the patch to be updated with said function test logic to auto-disable libcap2, modulo a fatal death on the --with-* case. Then for it to go back in :) OK. I'll give it a shot. Will make TPROXY require libcap-2.09 or later. At what version was libcap fixed for the issue we test in the magic sys/capability.h test case? Comment says libcap2 fixed, so I guess we no longer need this? Regards Henrik
Re: [MERGE] Use libcap instead of direct linux capability syscalls
Henrik Nordstrom wrote: tis 2009-10-27 klockan 14:46 +1300 skrev Amos Jeffries: I would like the patch to be updated with said function test logic to auto-disable libcap2, modulo a fatal death on the --with-* case. Then for it to go back in :) OK. I'll give it a shot. Will make TPROXY require libcap-2.09 or later. At what version was libcap fixed for the issue we test in the magic sys/capability.h test case? Comment says libcap2 fixed, so I guess we no longer need this? Regards Henrik Not entirely sure what version. I think the Gentoo 2.15 or 2.16 is fixed. My Ubuntu 2.11 is broken by the test results of last build I ran. I think we need to keep the magic voodoo for a while longer. Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE19 Current Beta Squid 3.1.0.14
Re: [MERGE] Use libcap instead of direct linux capability syscalls
ons 2009-10-28 klockan 01:35 +1300 skrev Amos Jeffries: Not entirely sure what version. I think the Gentoo 2.15 or 2.16 is fixed. My Ubuntu 2.11 is broken by the test results of last build I ran. Ok. The configure test was broken however, always reporting failure... I think we need to keep the magic voodoo for a while longer. It's still there. Regards Henrik
Re: [MERGE] Use libcap instead of direct linux capability syscalls
On Tue, 27 Oct 2009 15:08:24 +0100, Henrik Nordstrom hen...@henriknordstrom.net wrote: ons 2009-10-28 klockan 01:35 +1300 skrev Amos Jeffries: Not entirely sure what version. I think the Gentoo 2.15 or 2.16 is fixed. My Ubuntu 2.11 is broken by the test results of last build I ran. Ok. The configure test was broken however, always reporting failure... Strange. That was the change the Gentoo people are all enjoying at the moment. Amos
Re: [MERGE] Use libcap instead of direct linux capability syscalls
tis 2009-10-27 klockan 14:46 +1300 skrev Amos Jeffries: I would like the patch to be updated with said function test logic to auto-disable libcap2, modulo a fatal death on the --with-* case. Then for it to go back in :) Done. Regards Henrik
Re: [MERGE] Use libcap instead of direct linux capability syscalls
ons 2009-10-28 klockan 10:32 +1300 skrev Amos Jeffries: The configure test was broken however, always reporting failure... Strange. That was the change the Gentoo people are all enjoying at the moment. Well, I think most are silently happy with the workaround enabled even if not strictly needed. Regards Henrik
Re: [MERGE] Use libcap instead of direct linux capability syscalls
Alexander Huemer wrote: Amos Jeffries wrote: On Tue, 20 Oct 2009 01:04:26 +0200, Henrik Nordstrom hen...@henriknordstrom.net wrote: mån 2009-10-19 klockan 12:10 +1300 skrev Amos Jeffries: Um, is that function libcap2 specific? Not sure when it was added. Checking... seems to be 2.09. Added to the git repository Sat Mar 29 21:40:06 2008 -0700. There is also a libcap-ng project these days, with yet another API.. The other was mentioned as a possible requirement as well. I have not spent any time seeing whether its worth it or not to support libcap-ng. Do you know enough about them both to pick? It may be related to the LIBCAP_BROKEN identifier or another such test for the specific function may be worth adding... I rather have one code base than two here.. either libcap is used or it is not. Using libcap if found working or raw syscalls if not does not sound like a good idea to me. But maybe we can require a reasonably current libcap-2 for TPROXY support? It requires a custom kernel anyway on the systems with too old libcap implementations I think. We can do that yes. I think I would also rather do it too. It paves the way for a clean deprecation cycle now that TPROXYv4 kernels are effectively mainstream: 3.0: (2008-2010) TPROXYv2 with libcap + libcap2 3.1: (2010-2012) support TPROXYv2 + TPROXYv4 with libcap2 3.2: (2011?) support TPROXYv4 with libcap2 Amos i guess this fix went into squid 3.1.0.14 ... ? the gentoo package for that version just appeared in the portage tree and i installed it. no more warning messages in dmesg. good job! will this find it's way into squid 3.0 too ? or can i wait for 3.2 ? i did not find a planned release date. regards -alex The Gentoo hack fix is the only thing included so far (must be what you see in 3.1.0.14) and will also be in 3.0.STABLE20 when that comes out. Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE19 Current Beta Squid 3.1.0.14
Re: [MERGE] Use libcap instead of direct linux capability syscalls
tis 2009-10-20 klockan 12:52 +1300 skrev Amos Jeffries: We can do that yes. I think I would also rather do it too. It paves the way for a clean deprecation cycle now that TPROXYv4 kernels are effectively mainstream: 3.0: (2008-2010) TPROXYv2 with libcap + libcap2 3.1: (2010-2012) support TPROXYv2 + TPROXYv4 with libcap2 3.2: (2011?) support TPROXYv4 with libcap2 So you want me to add the patch back on trunk? Means we must update libcap on several of the build farm members, including the master, or disable TPROXY in the build tests.. I guess I could add some configure magics to look for the missing function and automatically disable.. Regards Henrik
Re: [MERGE] Use libcap instead of direct linux capability syscalls
On Tue, 27 Oct 2009 02:13:03 +0100, Henrik Nordstrom hen...@henriknordstrom.net wrote: tis 2009-10-20 klockan 12:52 +1300 skrev Amos Jeffries: We can do that yes. I think I would also rather do it too. It paves the way for a clean deprecation cycle now that TPROXYv4 kernels are effectively mainstream: 3.0: (2008-2010) TPROXYv2 with libcap + libcap2 3.1: (2010-2012) support TPROXYv2 + TPROXYv4 with libcap2 3.2: (2011?) support TPROXYv4 with libcap2 So you want me to add the patch back on trunk? Means we must update libcap on several of the build farm members, including the master, or disable TPROXY in the build tests.. I guess I could add some configure magics to look for the missing function and automatically disable.. Yes please. I would like the patch to be updated with said function test logic to auto-disable libcap2, modulo a fatal death on the --with-* case. Then for it to go back in :) Amos
Re: [MERGE] Use libcap instead of direct linux capability syscalls
Amos Jeffries wrote: On Tue, 20 Oct 2009 01:04:26 +0200, Henrik Nordstrom hen...@henriknordstrom.net wrote: mån 2009-10-19 klockan 12:10 +1300 skrev Amos Jeffries: Um, is that function libcap2 specific? Not sure when it was added. Checking... seems to be 2.09. Added to the git repository Sat Mar 29 21:40:06 2008 -0700. There is also a libcap-ng project these days, with yet another API.. The other was mentioned as a possible requirement as well. I have not spent any time seeing whether its worth it or not to support libcap-ng. Do you know enough about them both to pick? It may be related to the LIBCAP_BROKEN identifier or another such test for the specific function may be worth adding... I rather have one code base than two here.. either libcap is used or it is not. Using libcap if found working or raw syscalls if not does not sound like a good idea to me. But maybe we can require a reasonably current libcap-2 for TPROXY support? It requires a custom kernel anyway on the systems with too old libcap implementations I think. We can do that yes. I think I would also rather do it too. It paves the way for a clean deprecation cycle now that TPROXYv4 kernels are effectively mainstream: 3.0: (2008-2010) TPROXYv2 with libcap + libcap2 3.1: (2010-2012) support TPROXYv2 + TPROXYv4 with libcap2 3.2: (2011?) support TPROXYv4 with libcap2 Amos i guess this fix went into squid 3.1.0.14 ... ? the gentoo package for that version just appeared in the portage tree and i installed it. no more warning messages in dmesg. good job! will this find it's way into squid 3.0 too ? or can i wait for 3.2 ? i did not find a planned release date. regards -alex
Re: [MERGE] Use libcap instead of direct linux capability syscalls
On Tue, 20 Oct 2009 01:04:26 +0200, Henrik Nordstrom hen...@henriknordstrom.net wrote: mån 2009-10-19 klockan 12:10 +1300 skrev Amos Jeffries: Um, is that function libcap2 specific? Not sure when it was added. Checking... seems to be 2.09. Added to the git repository Sat Mar 29 21:40:06 2008 -0700. There is also a libcap-ng project these days, with yet another API.. The other was mentioned as a possible requirement as well. I have not spent any time seeing whether its worth it or not to support libcap-ng. Do you know enough about them both to pick? It may be related to the LIBCAP_BROKEN identifier or another such test for the specific function may be worth adding... I rather have one code base than two here.. either libcap is used or it is not. Using libcap if found working or raw syscalls if not does not sound like a good idea to me. But maybe we can require a reasonably current libcap-2 for TPROXY support? It requires a custom kernel anyway on the systems with too old libcap implementations I think. We can do that yes. I think I would also rather do it too. It paves the way for a clean deprecation cycle now that TPROXYv4 kernels are effectively mainstream: 3.0: (2008-2010) TPROXYv2 with libcap + libcap2 3.1: (2010-2012) support TPROXYv2 + TPROXYv4 with libcap2 3.2: (2011?) support TPROXYv4 with libcap2 Amos
Re: [MERGE] Use libcap instead of direct linux capability syscalls
fre 2009-10-16 klockan 02:04 +0200 skrev Henrik Nordstrom: fre 2009-10-16 klockan 11:03 +1300 skrev Amos Jeffries: /* NP: keep these two if-endif separate. Non-Linux work perfectly well Sorry.. thought I had fixed that already.. +#define PUSH_CAP(cap) cap_list[ncaps++] = (cap) I can just see that converting to: CAP_NET_ADMIN_ist[nCAP_NET_ADMINs++]=(CAP_NET_ADMIN) ... Nope.. preprocessor is tokens based. But as this macro is farily simple now it can just as well be expanded. I think the plan was to eventually C++ encapsulate these details, but that's overkill here. Updated patch attaced. Crap. libcap on centos is not usable. Regards Henrik
Re: [MERGE] Use libcap instead of direct linux capability syscalls
Henrik Nordstrom wrote: fre 2009-10-16 klockan 02:04 +0200 skrev Henrik Nordstrom: fre 2009-10-16 klockan 11:03 +1300 skrev Amos Jeffries: /* NP: keep these two if-endif separate. Non-Linux work perfectly well Sorry.. thought I had fixed that already.. +#define PUSH_CAP(cap) cap_list[ncaps++] = (cap) I can just see that converting to: CAP_NET_ADMIN_ist[nCAP_NET_ADMINs++]=(CAP_NET_ADMIN) ... Nope.. preprocessor is tokens based. But as this macro is farily simple now it can just as well be expanded. I think the plan was to eventually C++ encapsulate these details, but that's overkill here. Updated patch attaced. Crap. libcap on centos is not usable. Regards Henrik Um, is that function libcap2 specific? It may be related to the LIBCAP_BROKEN identifier or another such test for the specific function may be worth adding... Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE19 Current Beta Squid 3.1.0.14
Re: [MERGE] Use libcap instead of direct linux capability syscalls
Henrik Nordstrom wrote: The kernel interface, while some aspects of it is much simpler is also not really meant to be called directly by applications. The attached patch approximates the same functionality using libcap. Differs slightly in how it sets the permitted capabilities to be kept on uid change (explicit instead of masked), but end result is the same as setting the capabilities won't work if these were not allowed. /* NP: keep these two if-endif separate. Non-Linux work perfectly well without Linux syscap support. */ -#if defined(_SQUID_LINUX_) - -#if HAVE_SYS_CAPABILITY_H The above was done so that interception does not get disabled on FreeBSD which now has some TPROXY support. +#define PUSH_CAP(cap) cap_list[ncaps++] = (cap) I can just see that converting to: CAP_NET_ADMIN_ist[nCAP_NET_ADMINs++]=(CAP_NET_ADMIN) ... Otherwise good. Amos -- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE19 Current Beta Squid 3.1.0.14
Re: [MERGE] Use libcap instead of direct linux capability syscalls
fre 2009-10-16 klockan 11:03 +1300 skrev Amos Jeffries:
/* NP: keep these two if-endif separate. Non-Linux work perfectly well
Sorry.. thought I had fixed that already..
+#define PUSH_CAP(cap) cap_list[ncaps++] = (cap)
I can just see that converting to:
CAP_NET_ADMIN_ist[nCAP_NET_ADMINs++]=(CAP_NET_ADMIN) ...
Nope.. preprocessor is tokens based. But as this macro is farily simple
now it can just as well be expanded. I think the plan was to eventually
C++ encapsulate these details, but that's overkill here.
Updated patch attaced.
Regards
Henrik
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: hen...@henriknordstrom.net-20091015235726-\
# tjj24dnri2arionc
# target_branch: http://www.squid-cache.org/bzr/squid3/trunk/
# testament_sha1: e0544b31cc7e7f4f877a1b5939e6cfe26d60bc6f
# timestamp: 2009-10-16 01:58:06 +0200
# base_revision_id: squ...@treenet.co.nz-20091015121532-\
# hhwys6416uxebd9y
#
# Begin patch
=== modified file 'configure.in'
--- configure.in 2009-10-15 10:12:38 +
+++ configure.in 2009-10-15 14:28:22 +
@@ -2763,7 +2763,7 @@
fi
],[AC_MSG_RESULT(yes)])
if test x$use_caps = xyes; then
- dnl Check for libcap1 breakage or libcap2 fixed (assume broken unless found working)
+ dnl Check for libcap1 header breakage or libcap2 fixed (assume broken unless found working)
libcap_broken=1
AC_CHECK_HEADERS(sys/capability.h)
AC_CACHE_CHECK([for operational libcap2], $libcap_broken,
@@ -2773,6 +2773,7 @@
]])],[libcap_broken=0],[])
)
AC_DEFINE_UNQUOTED([LIBCAP_BROKEN],$libcap_broken,[if libcap2 is available and not clashing with libc])
+ AC_CHECK_LIB(cap, cap_get_proc)
fi
AC_CHECK_TYPE(mtyp_t,AC_DEFINE(HAVE_MTYP_T,1,[mtyp_t is defined by the system headers]),,[#include sys/types.h
=== modified file 'src/tools.cc'
--- src/tools.cc 2009-08-28 01:44:26 +
+++ src/tools.cc 2009-10-15 23:57:26 +
@@ -1241,50 +1241,40 @@
{
/* NP: keep these two if-endif separate. Non-Linux work perfectly well without Linux syscap support. */
#if defined(_SQUID_LINUX_)
-
#if HAVE_SYS_CAPABILITY_H
-#ifndef _LINUX_CAPABILITY_VERSION_1
-#define _LINUX_CAPABILITY_VERSION_1 _LINUX_CAPABILITY_VERSION
-#endif
-cap_user_header_t head = (cap_user_header_t) xcalloc(1, sizeof(*head));
-cap_user_data_t cap = (cap_user_data_t) xcalloc(1, sizeof(*cap));
-
-head-version = _LINUX_CAPABILITY_VERSION_1;
-
-if (capget(head, cap) != 0) {
-debugs(50, DBG_IMPORTANT, Can't get current capabilities);
-} else if (head-version != _LINUX_CAPABILITY_VERSION_1) {
-debugs(50, DBG_IMPORTANT, Invalid capability version head-version (expected _LINUX_CAPABILITY_VERSION_1 ));
+cap_t caps;
+if (keep)
+ caps = cap_get_proc();
+else
+ caps = cap_init();
+if (!caps) {
+ IpInterceptor.StopTransparency(Can't get current capabilities);
} else {
-
-head-pid = 0;
-
-cap-inheritable = 0;
-cap-effective = (1 CAP_NET_BIND_SERVICE);
-
-if (IpInterceptor.TransparentActive()) {
-cap-effective |= (1 CAP_NET_ADMIN);
+ int ncaps = 0;
+ int rc = 0;
+ cap_value_t cap_list[10];
+ cap_list[ncaps++] = CAP_NET_BIND_SERVICE;
+
+ if (IpInterceptor.TransparentActive()) {
+ cap_list[ncaps++] = CAP_NET_ADMIN;
#if LINUX_TPROXY2
-cap-effective |= (1 CAP_NET_BROADCAST);
+ cap_list[ncaps++] = CAP_NET_BROADCAST;
#endif
-}
-
-if (!keep)
-cap-permitted = cap-effective;
-
-if (capset(head, cap) != 0) {
+ }
+
+ cap_clear_flag(caps, CAP_EFFECTIVE);
+ rc |= cap_set_flag(caps, CAP_EFFECTIVE, ncaps, cap_list, CAP_SET);
+ rc |= cap_set_flag(caps, CAP_PERMITTED, ncaps, cap_list, CAP_SET);
+
+if (rc || cap_set_proc(caps) != 0) {
IpInterceptor.StopTransparency(Error enabling needed capabilities.);
}
+ cap_free(caps);
}
-
-xfree(head);
-xfree(cap);
-
#else
IpInterceptor.StopTransparency(Missing needed capability support.);
#endif /* HAVE_SYS_CAPABILITY_H */
-
-#endif /* !defined(_SQUID_LINUX_) */
+#endif /* _SQUID_LINUX_ */
}
void *
# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWeXFlV4ABjxfgEQwef///39v
/2q+YAnPj1q+owJFAC6wnTU1lAAoAMkTQSeRPUzQnpPakeiaaPU00GgAaaBo0aAA4yZNGgNG
mIyNDEMCaNMQYjQYQAGHGTJo0Bo0xGRoYhgTRpiDEaDCAAwYlSPFBiNMnkmAhpiYgDRoMAmjJkMJ
gikRojRpqniPSaaTKbFMyMQ1PTJqNEeiD1NBtQP1BJIBNNNAhCek1MaNJpH6oGRmoyMTR6mT1Hpp
PCjhAcBA/KxRq1hVPG4pZm3lBsotwW7hoeBiSZwQhH0/L5PH/kbyD/uLuplZbxN2y1f8fZogkkyC
aYHcL90IFWcSSwYKsiE+LyjBhNwLMnJqM1M9XJ8pp0hqwfSU6dKQuYVSv7m9a9R6u/J5/hu0DwLV
RcnDIAkUnMqGQkxuEOu/zzGEwQUAhFxmfXGk80CefYwUo9wwYQBxOcXyfCzqxcymxgpzi5iJF2EY
0U55YbSigl3BGUOeSjOVXxhd+FvrRBZasfyxaKQCJ8BskUW8K+C2l+leb4cJr4W3P2YqIV4EazdE
8uc3g5hmBhATdqv1zKZMU1u7PYqz7dBuGAPCEUqgRrsCOo6uAXo6SLqriqnF9gpXSmR5HTRV9R1w
70c8uFh1Rvee+vka9RAroY78lh1wpyiWupjVyVseZEn8VOsFimsDmAQ1hiiWNDJGbAgPJC0F+0TW
++nIjzgwJ/15qUHGK6ew0DchuHpVdSHu9mKHqu83NkJSlKUv4q17+o3uk1RctUCnrgZzP+b7Ub71
