Fix GH-19320: Prevent FPM UID and GID overflow

[prateekbhujel]

FPM parses numeric user, group, listen.owner, and listen.group values with strtoul(), but stores them in signed int fields. That can silently change an ID before it reaches setuid(), setgid(), or chown().

This stores the values in uid_t/gid_t and rejects IDs that the platform types cannot represent during config validation. It also rejects the all-bits-one value used by chown() as its no-change sentinel.

I added coverage for all four numeric directives and ran the full FPM test suite.

Fixes GH-19320

[bukka]

The logic makes sense to me. Just not sure about that shift if it's safe. If someone could re-check that would be great.

[bukka]

This should someone re-check but couldn't that shift be in some cases undefined (e.g. on 32bit)?

[prateekbhujel]

I re-checked this. UINTMAX_C(1) makes the left operand an unsigned uintmax_t, so on a 32-bit system this is a shift by 31 and is defined. uintmax_t is required to be able to represent any unsigned integer type, and this branch is only used when uid_t is signed. So this should be safe here, but I can add a short comment if you think it would make the intent clearer.

[arnaud-lb]

This looks right to me. Maybe add a comment to say that max specifically excludes -1 because it's a sentinel value, or check for -1 separately (I was confused by -2 at first).

[prateekbhujel]

Agreed, checking it separately is clearer. I pushed that now: max is the actual type maximum, and (uid_t)-1 / (gid_t)-1 are rejected explicitly as sentinels. The full FPM test suite still passes.

[arnaud-lb]

Looks good to me otherwise!

[arnaud-lb]

Nit: I would repeat ((uid_t) -1) here instead of reusing sentinel

[prateekbhujel]

Makes sense, done. I repeated the casts for both uid_t and gid_t, and kept sentinel only for the explicit rejection check. The focused test still passes.