Consider overly long paths

[stoeckmann]

Some of shadow's code, e.g. lib/commonio, limits internal paths to 1024 characters. While this is more than enough for regular paths like /etc/passwd and so on, the prefix flags would allow longer paths.

Either check if supplied arguments (and subsequent constructions of paths, e.g. backup files) fit into buffers or dynamically allocate these paths and just check if opening/creating these paths fail afterwards.

See #1497 (comment)

[alejandro-colomar]

I strongly prefer keeping limits and checking those.

GNU Hurd tends to prefer claiming not having limits, but that in reality just means that the limits are app-specific and not mandated by the OS, and the actual limits are not so well documented.

The traditional approach of having hardcoded system limits (e.g., libc's PATH_MAX) seems more robust to me, as every program is aware of a common set of limits.

Also, because of how the C language works (integer arithmetic, etc.), there are inherent limits always; it's just a matter of where exactly. It's safer to control the limits rather than letting attackers probe some unspecified limits.

And also, a program that claims to have no limits must increase use of heap allocations, which means having more failure points.

I'd just add checks for the limits (i.e., fail when we detect truncation).