Is your feature request related to a problem? Please describe.
Currently, Please's Linux sandbox uses user namespaces to isolate build actions, mapping the single UID and GID of the user running plz inside the sandbox.
While this single-ID mapping works fine for standard compilation steps, it limits local developer environments when trying to run more complex tasks inside the sandbox. If a build rule or test needs to execute tools that expect multiple UIDs/GIDs (e.g., building rootless container images, using fakeroot, running package managers like apt/dnf), the process fails with EPERM (Operation not permitted). This happens because any attempt to chown files or setuid to an unmapped ID is blocked by the kernel.
Describe the solution you'd like
Please's Linux sandbox should optionally support multi-UID and multi-GID mappings by leveraging the standard newuidmap and newgidmap utilities.
Describe alternatives you've considered
- Disabling the sandbox: allows these tools to run, but sacrifices hermeticity.
Currently, Please's Linux sandbox uses user namespaces to isolate build actions, mapping the single UID and GID of the user running plz inside the sandbox.
While this single-ID mapping works fine for standard compilation steps, it limits local developer environments when trying to run more complex tasks inside the sandbox. If a build rule or test needs to execute tools that expect multiple UIDs/GIDs (e.g., building rootless container images, using fakeroot, running package managers like apt/dnf), the process fails with EPERM (Operation not permitted). This happens because any attempt to chown files or setuid to an unmapped ID is blocked by the kernel.
Please's Linux sandbox should optionally support multi-UID and multi-GID mappings by leveraging the standard newuidmap and newgidmap utilities.