fix(supervisor-network): distinguish absent policy binary from filesystem-access failure - #2948
Conversation
…stem-access failure Signed-off-by: Artem Lytvyn <alytvyn@redhat.com>
|
/ok to test f7a386a |
PR Review StatusThis concentrated fix is project-valid against linked issue #2883. The initial review found no blocking defects; the typed resolution outcomes preserve literal matching while separating expected absent candidates from actionable process-root and symlink-chain failures. Blocking findings:
Carried findings:
Non-blocking suggestions:
Gator metadata
|
|
Label |
Signed-off-by: Artem Lytvyn <alytvyn@redhat.com>
f7a386a to
d8df79d
Compare
|
/ok to test d8df79d |
PR Review StatusThe follow-up review found no blocking defects in the latest author delta. The test-only setup reorder is safe, the prior diagnostic-path suggestion remains non-blocking, and current-head Branch Checks, Helm Lint, and E2E workflows are now dispatched. Blocking findings:
Carried findings:
Gator metadata
|
Monitoring CompleteMonitoring is complete because this PR has merged. Final status: The PR reached I removed the active |
Summary
resolve_binary_in_containerreported an absent non-glob policy binary candidate (ENOENT) with the same WARN as a genuine failure to access/proc/<pid>/root, wrongly telling operators to add CAP_SYS_PTRACE or canonicalize paths. Built-in profiles like pypi list multiple candidate layouts, so images using one layout emitted a burst of misleading warnings on every policy rebuild. This change classifies resolution outcomes into a typed result and logs absent candidates quietly while keeping genuine access failures actionable.Related Issue
Closes #2883
Changes
resolve_binary_in_container'sOption<String>return with a typedBinaryResolutionenum (Resolved, Literal, Absent, Inaccessible, ChainBroken); the resolver no longer logs.proto_to_opa_data_json): Resolved → info, Absent → debug, Inaccessible/ChainBroken → warn. Fixes a pre-existing double-log and a mislabeled broken-chain path./proc/<pid>/rootreachability up front: an unreachable process root (pid gone → ENOENT, or denied → EACCES) is classified Inaccessible, while a leaf ENOENT under a reachable root is Absent — resolving the errno ambiguity.Testing
Since I'm on macOS, I ran the Linux-only tests in a rust:latest Docker container to make sure the
#[cfg(target_os = "linux")]paths actually pass.mise run pre-commitpassesChecklist