brintos

brintos / linux public Read only

0
0

wasm32: capget(2) errors at runtime under gettid() != getpid() task model (native cap tools broken) #11

Open sasha opened this issue · 1 comment
S sasha commented

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>/status carries the caps; /proc/<tid> has no top-level entry.
  • With the syscall wired via __se_sys_capget (kernel links clean; syscall 125 dispatches through sys_call_table[125]; no hardwarejs-side filter), stock libcap-ng captest still prints Error getting capabilities and pscap -a lists nothing.
  • The userspace workaround that makes pscap/captest work reads caps from /proc/<getpid>/status (and had to switch gettidgetpid) — which is exactly the tell that the gettid-addressed capget is 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.