Running code on all other threads (for sandboxing)

Demi Marie Obenour demiobenour@gmail.com
Sat Aug 23 01:34:55 GMT 2025


There are cases where it is highly desirable for a process
to start out with full user rights (or at least close to them),
initialize, and then drop these privileges using Linux kernel
features like seccomp.  Unfortunately, this breaks if the
process uses third-party libraries that create threads during
initialization.  In particular, Mesa can do this, and there is
no realistic alternative to it as Mesa is ~2 million lines of
GPU compiler and driver code.  Loading Mesa later is undesirable
as it prevents removing all filesystem access.

There are two ways to fix this problem:

1. Fix the problem in the Linux kernel.
2. Work around it in userspace, as is already done for setuid()
   and friends.

For the second, it should be sufficient to provide a function
that runs a caller-provided function on each thread, while
ensuring that the process is atomic with respect to other
threads in the process.  This function only needs to make
system calls and crashes the process if there is an error.
If the function uses anything that isn't a syscall or
compiler builtin, it gets to keep both pieces.

Is this something that would make sense to implement?  I know
that this problem has been an issue for Chromium on Linux.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB288B55FFF9C22C1.asc
Type: application/pgp-keys
Size: 7140 bytes
Desc: OpenPGP public key
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250822/63a5084f/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250822/63a5084f/attachment-0001.sig>


More information about the Libc-alpha mailing list