act-root-container-bypasses-permission-bit-failure-injection

Answer

Solution written to ~/act-root-container-permission-bit-solution.md.

Summary

Root cause: act runs job containers as root by default. Root holds CAP_DAC_OVERRIDE (and CAP_DAC_READ_SEARCH), which per capabilities(7) "bypass[es] file read, write, and execute permission checks." So a test that injects EACCES via chmod 0500/0000 sees the kernel skip the DAC check entirely — the error never occurs and the assertion blows up. GitHub-hosted runners run as non-root (runner), so it only reproduces under act.

Fix: guard the injection tests with an euid check, centralized in one helper:

func requirePermissionBits(t *testing.T, euid int) {
    t.Helper()
    if euid == 0 {
        t.Skipf("euid=0: CAP_DAC_OVERRIDE bypasses permission bits; chmod-based EACCES injection is not reproducible")
    }
}

Called as requirePermissionBits(t, os.Geteuid()). Alternative for preserving coverage: act -j test --container-options "--user 1000".

What I verified locally (/tmp/repro, uid 1000): - chmod 0000 file read and chmod 0500 directory write both genuinely produce fs.ErrPermission natively. - The guard's root branch is proven to call t.Skip via a subtest (TestRequirePermissionBitsGuard/euid0), so the fix is verified without needing root. - go vet and go test are fully green.

Sandbox limitation: this environment blocks Docker (no daemon) and user-namespace uid mapping (NoNewPrivs=1, empty capability sets), so act/sudo root execution could not be exercised here. The document therefore includes the exact root-shell and act commands (plus the grep -- '---FAIL' log-parsing tip) to complete that last verification on a host with Docker.