fix: exec exit-code 127 vs 126 misclassification on 32-bit musl/seccomp

[Copilot]

On musl i486 (32-bit static) under Ubuntu 24.04, execvp returns EACCES instead of ENOENT for a non-existent path — likely because the GitHub Actions seccomp profile filters 32-bit execve syscalls differently. The old code used errno == ENOENT to distinguish exit 127 (not found) from exit 126 (not executable), so EACCES was misclassified as 126, failing assert(exit_code == 127) in test_limiter_run_command_mode_nonexistent.

Change

src/limiter.c — exec_child_process

For explicit paths (argument contains /), replace the errno-based 127-vs-126 decision with access(path, F_OK):

/* Before */
if (saved_errno == ENOENT && strchr(cfg->command_args[0], '/') != NULL &&
    access(cfg->command_args[0], F_OK) == 0) {
    _exit(EXIT_CMD_NOT_EXECUTABLE);          /* 126 */
}
_exit(saved_errno == ENOENT ? EXIT_CMD_NOT_FOUND : EXIT_CMD_NOT_EXECUTABLE);

/* After */
if (strchr(cfg->command_args[0], '/') != NULL) {
    _exit(access(cfg->command_args[0], F_OK) == 0
              ? EXIT_CMD_NOT_EXECUTABLE      /* file exists → 126 */
              : EXIT_CMD_NOT_FOUND);         /* file absent  → 127 */
}
_exit(saved_errno == ENOENT ? EXIT_CMD_NOT_FOUND : EXIT_CMD_NOT_EXECUTABLE);

access(F_OK) is the authoritative answer to "does the file exist" and is unaffected by whatever errno execvp returns. PATH-resolved names (no /) still fall back to errno since access cannot resolve them against $PATH.

[Copilot]

Pull request overview

Fixes misclassification of exec failure exit codes (127 vs 126) on 32-bit musl/seccomp environments where execvp returns EACCES instead of ENOENT for non-existent paths. For explicit paths containing /, the code now uses access(F_OK) as the authoritative existence check rather than relying on errno.

Changes:

• Replace errno-based 127-vs-126 decision with access(F_OK) for explicit paths in exec_child_process.
• Update the surrounding comment to document the rationale (musl/seccomp EACCES behavior).

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 296e9ff763

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve permission errors for explicit paths

When an explicit command path is inside a directory the caller cannot search, execvp() fails with EACCES and access(path, F_OK) also fails with EACCES even though the target may exist; the new ternary maps every access() failure to 127. This changes permission-denied/other lookup failures from the documented shell-compatible 126 to “command not found”; only ENOENT/ENOTDIR from the existence check should become 127, while EACCES and similar errors should remain 126.

Useful? React with 👍 / 👎.

[HiGarfield]

@copilot address this issue.

[HiGarfield]

@copilot address the issue:

When an explicit command path is inside a directory the caller cannot search, execvp() fails with EACCES and access(path, F_OK) also fails with EACCES even though the target may exist; the new ternary maps every access() failure to 127. This changes permission-denied/other lookup failures from the documented shell-compatible 126 to “command not found”; only ENOENT/ENOTDIR from the existence check should become 127, while EACCES and similar errors should remain 126.