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
