fix(util): avoid UID/GID wraparound when parsing process credentials

[cursor]

Summary

Fixes incorrect handling of UID/GID strings from user.Lookup when configuring child process credentials.

Bug and impact

• Scenario: process.user is set to a Linux account whose UID or GID string is outside the uint32 range (for example 4294967296), or is otherwise non-numeric.
• Impact: strconv.Atoi succeeds for large values, then uint32(u) silently truncates (e.g. 4294967296 → 0). GetSysProcAttr then sees uid <= 0 and does not set syscall.Credential, so git/ansible children may run as the wrong user (no privilege drop). That is a security/correctness failure on systems with unusual UID assignments.

Root cause

UID/GID from the password database are strings. Parsing with strconv.Atoi + uint32() allows wraparound; the removed u <= math.MaxUint32 check did not help because MaxUint32 equals int max on typical 64-bit Go, so overflow already happened at Atoi for larger strings.

Fix

• Parse with strconv.ParseUint(s, 10, 32) so values that do not fit in 32 bits are rejected instead of truncated.
• Centralized in parseLinuxCredentialUint with unit tests.

Validation

• go test ./util/... -short

  

[cursor]

Security review (automation)

Outcome: No medium, high, or critical vulnerabilities identified in the added or modified code.

What changed: parseLinuxCredentialUint replaces strconv.Atoi + uint32() for passwd-derived UID/GID. The previous pattern could silently wrap values ≥ 2³² to 0 (root) when setting syscall.Credential. The new path uses strconv.ParseUint(s, 10, 32), which rejects out-of-range values and rejects 0, avoiding truncation/wraparound.

Prior threads: Previous automation security-review threads were cleared so this assessment is the active one.

Slack-style summary: PR3808 security pass — no exploitable issues in diff; change closes a credential truncation/wrap risk on Linux process credentials.

  

_{Sent by Cursor Automation: Find vulnerabilities}