Thanks for finding this. Fixed in: https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=f25a1b7e69f7b33e6afb58b3e38f3450b7d2d9a0 Cheers Andrew On Wed, Jan 19, 2022 at 6:08 AM Cristian Rodríguez <crrodriguez@xxxxxxxxxxxx> wrote: > > On Wed, Jan 19, 2022 at 10:57 AM Cristian Rodríguez > <crrodriguez@xxxxxxxxxxxx> wrote: > > > This is not a glibc problem though, looks like lcap is clobbering > > errno. I'd bet good CLP on the code called in > > __attribute__((constructor (300))) static void _initialize_libcap(void) . > > I strongly suggest not to use constructors on shared libraries unless > > all the components using the library are in your control and you are > > sure constructors will not ruin some other application's day. > > __attribute__((constructor (300))) static void _initialize_libcap(void) > { > if (_cap_max_bits) { > return; > } > cap_set_syscall(NULL, NULL); --> nope > _binary_search(_cap_max_bits, cap_get_bound, 0, __CAP_MAXBITS, > __CAP_BITS); --> 🤔 > cap_proc_root("/proc"); > } > > do, what cap_get_bound does ? > > int cap_get_bound(cap_value_t cap) > { > int result; > > result = prctl(PR_CAPBSET_READ, pr_arg(cap), pr_arg(0)); > if (result < 0) { > errno = -result; --> If all my bets paid , I would be rich.. > here is your 1 > return -1; > } > return result; > }
