[retr0h]

The process endpoints declare required,min=1 on their pid path parameter. Nothing enforced it.

What was wrong

Both handlers validated the hostname and then took the pid as given:

// process_signal_post.go
if errMsg, ok := validateHostname(request.Hostname); !ok { ... }
if errMsg, ok := validation.Struct(request.Body); !ok { ... }   // the signal name
pid := request.Pid                                              // nothing

The provider validated the signal name and called syscall.Kill(pid, sig) with the pid unchecked. allowedSignals includes KILL.

min=1 is the load-bearing rule here, not required. kill(2) overloads the sign of its first argument:

pid	meaning
> 0	that one process
0	every process in the caller's process group
-1	every process the caller may signal
< -1	every process in process group -pid

required on an int only rejects 0. Everything below it passes required and is caught by min=1 alone. The agent generally runs as root on a managed host, so the sign is the difference between stopping one process and stopping the host. A caller holding process:write to stop a runaway process had the second available to them, and 0 is an easy accident rather than only an attack.

The fix

Validated in both layers, because https://osapi-io.github.io/specs/components/osapi/providers says the request path does not discharge the provider's own checks, and the provider is the frame that actually calls kill(2):

• validatePid in the API package, mirroring the declared tag, called in process_get.go and process_signal_post.go.
• A guard in the Debian provider's Signal and Get. It runs before the signal name is looked up, so a bad pid is refused whatever signal arrives with it. Darwin and Linux are ErrUnsupported stubs and need nothing.

The 400 also now says what to do. validation.Var has no field name to report and min carries no hint, so the bare message was:

Key: '' Error:Field validation for '' failed on the 'min' tag

It now leads with pid -1 must be greater than zero and keeps the tag's message after it, so a test can still assert which rule rejected the request.

Tests

Four provider cases covering 0, -1, a process group, and a bad pid with a bad signal name. Each sets no mock expectation, so gomock fails the test if Kill is reached at all. That is the assertion that matters; checking the error string alone would pass even if the signal had been sent first.

Five HTTP cases across both endpoints asserting the body names required (for 0) or min (for negatives).

Verified against a running controller and agent

Before:

get pid=-5  exit=0  {"job_id":"c58b738f-...","results":[{...,"status":"skipped"}]}

It became a job and crossed NATS. After, 0, -1, -5 and -42 are all refused at the API with no job created.

How it was found

By going back through the min declarations one call site at a time to check whether the rule was load-bearing, after an audit had reported it as untestable and I had wrongly concluded the declarations were redundant. On 146 plain string fields required genuinely does mask min. Seven are not strings, and on this one min was the only guard and it was not wired up.

just test passes, coverage 100%.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FuKUsHFG1EqZXamffh9M2c

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

@@           Coverage Diff           @@
##             main     #593   +/-   ##
=======================================
  Coverage   99.95%   99.95%           
=======================================
  Files         501      501           
  Lines       24099    24120   +21     
=======================================
+ Hits        24089    24110   +21     
  Misses         10       10           

Files with missing lines	Coverage Δ
...nternal/controller/api/node/process/process_get.go	100.00% <100.00%> (ø)
...controller/api/node/process/process_signal_post.go	100.00% <100.00%> (ø)
internal/controller/api/node/process/validate.go	100.00% <100.00%> (ø)
internal/provider/node/process/debian.go	99.04% <100.00%> (+0.10%)	⬆️

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2f036a6...30aa04f. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.