rust
rust copied to clipboard
rust-lang
Expand documentation of PathBuf, discussing lack of sanitization
Various methods in PathBuf, in particular set_file_name and set_extension accept strings which include path seperators (like ../../etc). These methods just glue together strings, so you can end up with strange strings.
This isn't reasonable to change/fix at this point, and might not even be fixable, but I think should be documented. In particular, you probably shouldn't blindly build paths using strings given by possibly malicious users.
r? @workingjubilee
rustbot has assigned @workingjubilee. They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.
Use r? to explicitly pick a reviewer
I think it'd be better if we fixed this at least for PathBuf::set_extension, where I can't come up with a legitimate use case: #125070.
I think this should be discussed before I make a decision to accept or reject this, given that this implies some pretty hefty security concerns or usability questions, either way.
Just to say, I did send a message about this issue to security@rust-lang, before posting it, just in case it was deemed as a security issue, but after discussion I was told it wasn't considered a security issue.
I assumed possibly breaking existing code by adding panics would be considered a no-no, even when that code is doing some very silly things, but I have no idea what is acceptable.
I assumed possibly breaking existing code by adding panics would be considered a no-no, even when that code is doing some very silly things, but I have no idea what is acceptable.
We inject new panics all the time. We promise not to break builds, and mostly by preserving type signatures, and that's very different.
It's true we don't necessarily want to panic frivolously, but it's hard to argue this is frivolous.
Just to say, I did send a message about this issue to security@rust-lang, before posting it, just in case it was deemed as a security issue, but after discussion I was told it wasn't considered a security issue.
Regarding this, "A security issue in the sense that the rust-lang security response team has to handle it" is somewhat different than "a security issue for consideration by Rust programmers". One is "the stdlib has a CVE in it", basically, the other is "if you mishandle this, you have a CVE in your program". Some of this is a semi-arbitrary decision as to who gets to handle the blame, but when it's not possible for a programmer to avoid, or it involves memory soundness in purely safe code, that falls squarely on us.
We discussed this in the library team meeting today. We decided to apply the change in #125070 which makes set_extension panic if the extension contains invalid characters. This PR should be changed to only apply to set_filename.
Perhaps we (I?) could do a quick survey to see whether this is a used feature.
One concern we had was that making this function panic would allow arbitrary user input to cause a program to panic. This can be a problem e.g. in a network service, especially if there is code to validate the path after it has been formed with set_filename.
One concern we had was that making this function panic would allow arbitrary user input to cause a program to panic. This can be a problem e.g. in a network service,
I think a network service will likely contain panics to the connection level anyway, otherwise it'll likely be vulnerable to DoS.
Based on the comments when initiating the FCP on the other function, here: https://github.com/rust-lang/rust/pull/125070#issuecomment-2112985376
Though if we were confident that were not the case we'd love to do that too.
And the fact that, well, I think @tbu- has a good point, here, basically...
If @rust-lang/libs-api is willing, then I believe we should document the non-sanitizing behavior with an explicit note that set_file_name may panic in the future if you use it with something that is not, well, a file name.
Other ideas that aren't necessarily critical to address in this PR: We should also suggest a pattern that clearly denotes the "yes, I know I am joining arbitrary paths together, possibly with 'hilarious' results". We might suggest, for instance, path_buf.extend(path) or path.join(other_path) for "yes, I am clearly adding a multi-part path" cases.
I believe this is the sort of commentary in the documentation that will eventually provoke feedback and inform whether we should zig... er, not the programming language... or zag.
@ChrisJefferson What do you think?
@workingjubilee I think that's a good idea. It might also be worth adding fallible variants of these routines. I imagine in some cases, the inputs to these routines will come directly from end users. And in those cases, using a fallible routine is probably what you want.
Neat.
Also @ChrisJefferson I realize that feedback is slightly open-ended so all it really needs is the note about "set_file_name may panic in the future", if you wanna punt on the rest of it feel free to open an issue and I'll look at getting that sorted Eventually™.