Bug 219456

I'm filing this bug to find a different way to transparently reconfigure libcap to use the libpsx functions when a binary is linked with both -lcap and -lpsx. The intention being that this linking arrangement causes libcap to operate with a shared security context over the process.

Today, libcap recognizes that libpsx has been linked by calling psx_load_syscall() at library initialization time. Inside libcap, this function is actually defined as 

   __attribute__((weak))
   psx_load_syscall(...)

and the same function is defined in libpsx, but not with a weak attribute. So, if libpsx is linked into the application, libpsx's version dominates that of libcap. This combines to cause the libpsx version to provide the needed functions when libcap:cap_set_syscall() calls it.

In libcap-2.71 and earlier, libpsx could be forced to be linked because it was the library that provided the only definition of __real_pthread_create() and the linkage instructions for -lpsx were:

   -wrap,pthread_create -lpsx

which required __real_thread_create() to exist somewhere in the linked binary.

With libpsx-2.72 (not yet released) we've rewritten libpsx to not implement its functionality with respect to the pthread abstraction, but against Linux's native thread implementation. As such, the only remaining reason for the wrapping is to force libpsx to be linked against the binary.

So, strictly speaking, the pthread_create() function is no longer important to libpsx use. However, I've not yet found an alternate way to force libpsx.a or libpsx.so to actually link in the quiet libcap linking mode I want. So, I've had to retain the -wrap stuff with what will become libcap-2.72.

This bug is to find a better way to silently help libcap recognize it has been linked to a binary with libpsx, and to force -lpsx to actually link against a binary when nothing in that binary calls libpsx functions.