Bug 156799
| Summary: | File URLs should be passed through 'fileSystemRepresentation' before use | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Brent Fulgham <bfulgham> |
| Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | ap, bfulgham |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=156747 | ||
Brent Fulgham
We need to audit WebKit code to make sure that we always call fileSystemRepresentation before using a URL path as a file system path, and ideally make the compiler check that for us.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Brent Fulgham
It looks the following places need to be changed:
Internals::createFile
WebProcessProxy::hasAssumedReadAccessToURL
WebProcessProxy::checkURLReceivedFromWebProcess
WebPageProxy::loadFile
I think the point of fileSystemRepresentation is to ensure that the path is compatible with POSIX APIs. Are there reasons why we might want to deal with non-POSIX paths inside WebKit, up until the point where we actually pass them off to POSIX routines?
Brent Fulgham
I reviewed the various places where a file path is retrieved from a URL. It looks like in all cases we call fileSystemRepresentation on the path (or hand it to a function that in turn calls fileSystemRepresentation on its argument).
The two places in WebProcessProxy that use the method do so to retrieve a string for later use in comparing with a path. Since that paths in both places are retrieved without calling fileSystemRepresentation, it seemed better to leave these unmodified since the extra conversion wouldn't provide any additional safety, but would incur a runtime penalty.