Expand documentation of PathBuf, discussing lack of sanitization #125060
Conversation
|
rustbot has assigned @workingjubilee. Use |
rustbot
added
S-waiting-on-review
This is likely never intended and potentially a security vulnerability if it happens. I'd guess that it's mostly literal strings that are passed to this function in practice, so I'm guessing this doesn't break anyone. CC rust-lang#125060
|
I think it'd be better if we fixed this at least for |
This is likely never intended and potentially a security vulnerability if it happens. I'd guess that it's mostly literal strings that are passed to this function in practice, so I'm guessing this doesn't break anyone. CC rust-lang#125060
|
I think it's working-as-intended for the |
workingjubilee
added
I-libs-nominated
|
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. |
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. |
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. |
workingjubilee
added
the
I-libs-api-nominated
|
We discussed this in the library team meeting today. We decided to apply the change in #125070 which makes |
Amanieu
removed
I-libs-nominated
|
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 |
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: #125070 (comment)
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 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, 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 " |
…ratt Panic if `PathBuf::set_extension` would add a path separator This is likely never intended and potentially a security vulnerability if it happens. I'd guess that it's mostly literal strings that are passed to this function in practice, so I'm guessing this doesn't break anyone. CC rust-lang#125060
Panic if `PathBuf::set_extension` would add a path separator This is likely never intended and potentially a security vulnerability if it happens. I'd guess that it's mostly literal strings that are passed to this function in practice, so I'm guessing this doesn't break anyone. CC rust-lang#125060
Panic if `PathBuf::set_extension` would add a path separator This is likely never intended and potentially a security vulnerability if it happens. I'd guess that it's mostly literal strings that are passed to this function in practice, so I'm guessing this doesn't break anyone. CC rust-lang#125060
| /// | ||
| /// p.set_extension("/darkest.cookie"); | ||
| /// assert_eq!(Path::new("/feel/the./darkest.cookie"), p.as_path()); |
There was a problem hiding this comment.
This API was changed to panic.
| /// | |
| /// p.set_extension("/darkest.cookie"); | |
| /// assert_eq!(Path::new("/feel/the./darkest.cookie"), p.as_path()); |
| /// The new `extension` is not sanitized, so may include separators. | ||
| /// |
There was a problem hiding this comment.
This API was changed to panic.
| /// The new `extension` is not sanitized, so may include separators. | |
| /// |
| /// path.push(r"..\otherdir"); | ||
| /// path.push("system32"); | ||
| /// | ||
| /// path.set_extension(r"\..\temp"); |
There was a problem hiding this comment.
| /// path.set_extension(r"\..\temp"); |
Various methods in
PathBuf, in particularset_file_nameandset_extensionaccept 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.