4 ms·

If you don't want to do that, you don't have to. You could just not interact with with filesystems you dislike. Or you could interact with it but purposefully i

by atoav 2y ago

If you don't want to do that, you don't have to. You could just not interact with with filesystems you dislike. Or you could interact with it but purposefully ignore any error handling. The point I made is: this is an existing problem that could fail your mission critical code. Rust just tells you this could be a problem before it becomes one, it does not force you to care or pick a specific solution to solve the problem. With most other languages you would only find out about this error once it happens in production, if you ever find out about it. Going back to the user and asking them for a valid filename is also a form of error handling in my book. Of course ideally file systems would support all filenames and ideally they wouldn't suck, but we write software within a world that is not ideal.

kazinator 2y ago
> Going back to the user and asking them for a valid filename is also a form of error handling in my book. You cannot get away from error handling because there are multiple reasons why a name cannot be used, not all of them having to do with its form. So, on Unix-like systems, do you use a special Rust string type which doesn't allow slashes or nulls? So that if the regular string fails to convert to that string, you know that it's not a valid name, and you get brownie points for having found that without passing it to the OS? Also, whenever you divide numbers a / b, always be sure to use a special numeric type for b which doesn't have zero in its domain. Then if the input type doesn't convert to that type, you know at compile time you could have a division by zero.
- atoav 2y ago
  > and you get brownie points for having found that without passing it to the OS? You should probably reconsider your security model. Did you really just suggest passing arbitrary input to your OS filesystem to see if it fails? You can probably (hopefully?) figure out yourself why this is a bad idea. Ever heard of defense in depth? Sanitizing your inputs early and knowing why things failed is a good things. Having an additional redundant layer is not a bug, but a feature, especially if the underlaying layer has shown to be exploitable. Also consider that if you process user provided filenames you have to sanitize them anyways, unless you want them to give you filenames like /root/.ssh/authorized_keys
  - kazinator 2y ago
    > 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.

by atoav 2y ago

kazinator 2y ago

> Going back to the user and asking them for a valid filename is also a form of error handling in my book. You cannot get away from error handling because there are multiple reasons why a name cannot be used, not all of them having to do with its form. So, on Unix-like systems, do you use a special Rust string type which doesn't allow slashes or nulls? So that if the regular string fails to convert to that string, you know that it's not a valid name, and you get brownie points for having found that without passing it to the OS? Also, whenever you divide numbers a / b, always be sure to use a special numeric type for b which doesn't have zero in its domain. Then if the input type doesn't convert to that type, you know at compile time you could have a division by zero.

atoav 2y ago
> and you get brownie points for having found that without passing it to the OS? You should probably reconsider your security model. Did you really just suggest passing arbitrary input to your OS filesystem to see if it fails? You can probably (hopefully?) figure out yourself why this is a bad idea. Ever heard of defense in depth? Sanitizing your inputs early and knowing why things failed is a good things. Having an additional redundant layer is not a bug, but a feature, especially if the underlaying layer has shown to be exploitable. Also consider that if you process user provided filenames you have to sanitize them anyways, unless you want them to give you filenames like /root/.ssh/authorized_keys
- kazinator 2y ago
  > 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.