> On Jan 31, 2026, at 12:17 PM, Amit <[email protected]> wrote: ...
> In my opinion, denial of service is better than getting hacked. In > DoS, no personal information is leaked. But if someone gets hacked > then his/her personal information can be leaked. No. In some environments, it's much more important to keep the system running *even* if information leaks. In hospitals, for example, leaking medical records is bad, but having people die because the equipment won't run (availability) is much worse. The normal definition of security includes confidentiality, integrity, AND availability. The weights of each factor depends on the use case. Systems built to comply with POSIX are used by all of the fastest computers in the world, most containers on clouds, a majority of smartphones, almost all TVs, and many other systems. Any proposal must work in ALL such cases. Accepting arbitrary proposals would make systems LESS secure, which is the opposite of the stated goal. ... > I can't think of any input that is always invalid. It depends on the > function. For some functions, even NULL may be a valid value. In that case, the proposal doesn't belong in POSIX! That said, I'm supportive of reasonable validations. I *do* think there are cases where certain inputs are always invalid, and thus, there *are* cases where I think it *does* make sense to forbid certain values. I previously proposed that at least \n, and preferably all control characters (bytes 1-31 in ASCII & UTF-8), be expressly *forbidden* in filenames: https://austingroupbugs.net/view.php?id=251 There is no user-level functionality *requiring* this capability, several systems (like MacOS) already forbid them, many users didn't know this was possible, and the mechanism's primary purpose appears to be to enable attackers to subvert systems. Many *existing* vulnerabilities build on this unwise permission. I still think that proposal is a good idea, and I'd love to see it re-opened! However, that proposal was rejected. That said, changes *were* made to POSIX to improve security because of that proposal. Since filenames with \n continue to be permitted, several utilities were modified to make it easier to portably handle \0 terminators so it is easier to write secure software in the presence of \n in filenames: * find -print0: https://austingroupbugs.net/view.php?id=243 * xargs -0: https://austingroupbugs.net/view.php?id=244 * shell -d "": https://austingroupbugs.net/view.php?id=245 Arbitrary values like an unconfigurable "X% of RAM" limit don't help security. They would make systems LESS secure, because they'd sometimes give attackers an easy way to remotely disable systems. That would also increase the burden on developers, who would suddenly have to code around weird arbitrary limits of their underlying system. Even adding special configuration capabilities has problems, because now users have to figure out a new special configuration. If you can show a *specific* kind of vulnerability due to a lack of input validation, and an input validation for that specific API that would apply in all cases and counter it, then that might be worth proposing. --- David A. Wheeler
