Also I am not sure how rust solves this bug, I don't think it's about memory safety is it? This is about passing -1 from a config file to a syscall, and sudo not validating the value or it being written without the understanding of what -1 means to that syscall. Nothing is mis-parsed, no buffers overflowed, etc.
It's a type confusion mistake (-1, meaning "no user ID", being the same type as an actual user ID). Idiomatic Rust would largely prevent this kind of mistake (you'd use an enum type, with a distinct value for "no user"), as long as someone first writes an idiomatic Rust wrapper for the syscalls.
Obviously, if you write the Rust the same way you'd write the C, then yeah, the mistake is equally likely to happen. Rust encourages style that avoids this kind of problem, but it can't enforce it.
So supposing you have a type that can either be a uid_t or no value... Can you specify that the high bit on the uid_t cannot be set? I.e. prevent an explicit stuffing of negative values (or unsigned values that are bit-identical to negative ones in the corresponding signed types) into such a type?
That is the most explicit way I can think of to block this with a type system. If uid_t is 32 bits, you need a type that can either contain 31 bits or no value, to prevent that 32nd bit being stuffed into the syscall somehow.
If backward compatibility is not required, then OpenBSD's doas[0] may be a suitable alternative. Someone[1]'s ported it to other UNIX-like systems, though I don't know how good the port is.
The problem is that sudo is an attempt to hack around the piss-poor Unix security model. Doing the same in a different language will hit the same fundamental problems.
