> Did you really just suggest passing arbitrary input to your OS filesystem to see if it fails? Yes? This is what I expect from programs as a user. Whatever in

> Did you really just suggest passing arbitrary input to your OS filesystem to see if it fails? Yes? This is what I expect from programs as a user. Whatever input I give them that is intended for the OS, should be passed through to the OS verbatim. There may be some very specific exceptions to that, but that's the general principle. > You can probably (hopefully?) figure out yourself why this is a bad idea. I've not seen this after 42 years of coding, sorry. > Having an additional redundant layer is not a bug, It can easily turn into a bug where second-guessing the user's OS turns into some kind of hindrance where they are not able to do something they should be able to do. It's a waste of time coding it. It erodes consistency. One program in one language/runtime restricts things one way; another one has a slightly different idea. > Sanitizing your inputs early and knowing why things failed is a good things. You don't seem to have a fully developed intuition for when this concept applies. > unless you want them to give you filenames like /root/.ssh/authorized_keys I've never seen an application that actually has a list of banned filenames like /root/.ssh/authorized_keys and checks every user input against it. It's a complete nonstarter. If the user wants to tell a program to overwrite /root/.ssh/authorized_keys, the program should just do it. If the user is not root, that path should not be accessible. If the user is root, it may be allowed to overwrite it even if it has no write permissions. The system security model and configuration has decide that; it's not the application's business to second-guess that policy.