Summary
Even with capget/capset wired into the wasm32 syscall table (see the
sys_capget alias issue), native capget(2) still errors at runtime, so
libcap-ng pscap/captest report Error getting capabilities. Strongly
supported root cause (not fully proven — exact errno not captured): the
main-thread gettid() (35) differs from getpid() (34) on this runtime, and
libcap-ng addresses "self" by gettid(), so capget(hdr.pid = gettid) does not
resolve the calling task.
Evidence
On core-image-brintos-emcraft (glibc), in-browser:
getpid()= 34, main-thread tid (via/proc/self/task) = 35 — i.e. tid != pid for the main thread./proc/<pid>/statuscarries the caps;/proc/<tid>has no top-level entry.- With the syscall wired via
__se_sys_capget(kernel links clean; syscall 125 dispatches throughsys_call_table[125]; no hardwarejs-side filter), stock libcap-ngcapteststill printsError getting capabilitiesandpscap -alists nothing. - The userspace workaround that makes
pscap/captestwork reads caps from/proc/<getpid>/status(and had to switchgettid→getpid) — which is exactly the tell that thegettid-addressedcapgetis the failing path.
Expected
For the main thread, gettid() == getpid() == tgid (as on native Linux), and
capget(hdr.pid = self-pid) resolves and returns the caller's capability set.
Impact
Blocks native process-capability tools (libcap-ng pscap/captest/netcap,
util-linux setpriv). Worked around in userspace today (libcap-ng reads
/proc). Together with the capget syscall wiring (kernel) and the
llvm-objcopy/parseRelocSection robustness fix, this is the runtime piece a
native fix needs. Reproducible on sasha/core-image-brintos-emcraft-glibc.
Notes
Not narrowed to a single line — the exact capget errno was not captured.
Likely candidates: the task/pid model assigning tid != pid for the main thread,
and/or capget's find_task_by_vpid on this runtime.