feat: add uid and gid support for command execution

[joaquinescalante23]

Summary

• Add uid and gid fields to RunCommandRequest for command execution
• Implement credential support in execd runtime using SysProcAttr on Linux
• Update Python, JavaScript, Kotlin, and C# SDKs with new options
• Update OpenAPI specification with new fields

Motivation

This feature allows users to run commands as specific users in the sandbox for better security isolation and access control.

Changes

• execd component: Added uid/gid to model and runtime (Linux only)
• Python SDK: Added uid and gid parameters to RunCommandOpts
• JavaScript SDK: Added uid and gid options to RunCommandOpts
• Kotlin SDK: Added uid() and gid() builder methods
• C# SDK: Added Uid and Gid properties to RunCommandOptions

[CLAassistant]

All committers have signed the CLA.

[Sophie-Emm]

Love the changes made, and the added security measures!

[joaquinescalante23]

Thanks for the detailed review, @Pangjiping . Great point about the supplemental groups. I definitely overlooked that they wouldn't be inherited correctly just by setting Uid/Gid in SysProcAttr.
Regarding the default value ambiguity (UID 0 vs unset), I see the issue with the current design in Go/Protobuf. Would you prefer I use a pointer for the UID/GID fields to distinguish between 'not set' and 'root', or should I implement a separate boolean flag to check if they were explicitly provided?
I'll wait for your guidance on the preferred pattern before updating the implementation. Thanks for catching those edge cases!

[Pangjiping]

Thanks for the detailed review, @Pangjiping . Great point about the supplemental groups. I definitely overlooked that they wouldn't be inherited correctly just by setting Uid/Gid in SysProcAttr. Regarding the default value ambiguity (UID 0 vs unset), I see the issue with the current design in Go/Protobuf. Would you prefer I use a pointer for the UID/GID fields to distinguish between 'not set' and 'root', or should I implement a separate boolean flag to check if they were explicitly provided? I'll wait for your guidance on the preferred pattern before updating the implementation. Thanks for catching those edge cases!

Whether to provide "zero values" has always been a criticized design in Go. A simple way to handle this is that you can receive uid/gidas pointers in execd.

[joaquinescalante23]

Thanks for the feedback, @Pangjiping. I've updated the implementation to address the UID/GID zero-value ambiguity by using pointers (*uint32) in ExecuteCodeRequest, as suggested.

In addition to handling the identity of the process correctly (distinguishing between root 0 and unset), I've also implemented support for supplemental groups. The execution process now uses os/user.LookupId to load and populate the Groups field in syscall.Credential. This ensures the child process maintains its full identity and permissions, resolving the issue where it would lose secondary group access.

If the Gid is omitted but a Uid is provided, the process now correctly defaults to the user's primary GID. Let me know if you have any further thoughts!

[Pangjiping]

Thanks for the feedback, @Pangjiping. I've updated the implementation to address the UID/GID zero-value ambiguity by using pointers (*uint32) in ExecuteCodeRequest, as suggested.

In addition to handling the identity of the process correctly (distinguishing between root 0 and unset), I've also implemented support for supplemental groups. The execution process now uses os/user.LookupId to load and populate the Groups field in syscall.Credential. This ensures the child process maintains its full identity and permissions, resolving the issue where it would lose secondary group access.

If the Gid is omitted but a Uid is provided, the process now correctly defaults to the user's primary GID. Let me know if you have any further thoughts!

LGTM. It seems there are some linter errors, you can run make golint under components/execd directory to find and fix them.