fix: java driver on macOS fails with operation not permitted (rootless)

[mvanhorn]

Description

The java task driver defaults user="nobody", and the relocated setCmdUser in drivers/shared/executor/executor_unix.go (built on //go:build unix, so it compiles on macOS) now sets a syscall Credential that fails rootless fork/exec on darwin, where it used to be a no-op. This guards the credential block with runtime.GOOS != "darwin" so the java driver works on macOS again, plus a unit test and a make cl changelog entry.

This change was implemented with AI assistance (an agent) from a written plan and reviewed before submission.

Testing & Reproduction steps

Added executor_unix_test.go covering the darwin path. Reproduction: on macOS, run a java-driver task as a non-root user; before the fix the credential set fails fork/exec with "operation not permitted".

Links

Fixes #28157

Contributor Checklist

• Changelog Entry (.changelog/28157.txt added)
• Testing (added executor_unix_test.go)
• Documentation (no user-facing docs change)
• LLM Usage Disclosed above: this change was implemented with AI assistance and reviewed by a human before submission.

Reviewer Checklist

• Backport Labels

• Commit Type

• Enterprise PRs

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

No changes to security controls. The change narrows when a syscall credential is set (skips it on darwin), which does not alter access controls, encryption, or logging.

[chrisroberts]

Hi @mvanhorn, thanks for this PR! While this initial changeset fixes the issue you are encountering, it would result in new issues for other users. The Darwin platform does support modifying the group/user of the process, and by default Nomad will set that to "nobody". Removing that functionality on Darwin would be removing an expected behavior.

The underlying issue here really seems to be the operation of Nomad without the privileges to set the user on the process (rootless). In that case, a better approach here would likely be modifying how the default user is set: If the user is not provided in the configuration, and the Nomad process has permission to change the user of a new process, then set the value to "nobody". Otherwise, make no adjustments.

Since the setCmdUser function is only called if command.User is a non-empty value, the resulting behavior would be the new process starting as the Nomad user.

Let me know if you have any questions or concerns, happy to help 🙂 .

[chrisroberts]

This change would remove support for setting the process user on Darwin, which is supported by the platform.

[mvanhorn]

Reworked per your suggestion in bb72063: the Darwin user-setting path is restored, and the nobody default now only applies when the Nomad process can actually set the user of a new process. Rootless Nomad leaves the user unset, and an explicitly configured user keeps working on Darwin. Added unit tests covering the four privilege/config combinations.