Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup/Improve storage.py #512

Merged
merged 13 commits into from
Feb 26, 2017
Merged

Cleanup/Improve storage.py #512

merged 13 commits into from
Feb 26, 2017

Conversation

Unrud
Copy link
Collaborator

@Unrud Unrud commented Sep 4, 2016

a12ef69 and 5dbf9df add missing checks for safe conversion of paths to the local filesystem. They are only relevant on Windows and currently it's not possible to exploit it.

6df54bf adds a log message that includes the name of a faulty component. Before only the exception from vobject showed up in the log but the filename of the component that caused the error was missing.

The Collection.get method stripped {} from href, 03fbb1e removes that. If someone uploaded a component that starts or ends with { or }, all REPORT requests on that collection failed and it was impossible to delete the component.
@liZe Why was that there in the first place? I couldn't find something like this in the relevant RFCs and hope removing it doesn't break some client.

de09f66 changes last_modified to only look at relevant files.

All other changes are just cosmetic.

Unrud added 13 commits September 4, 2016 12:52
On Windows 1/2 would be a safe filesystem path component, but it's not safe to pass it to path_to_filesystem.
Currently only the get method can be called with a href like that and it checked for that.
This just moves the check into the is_safe_filesystem_path_component function.
Etags are not checked in storage anymore and this is unused.
Currently it's not possible to exploit these.
They are unnecessary since the discover methods stopped returning collections that actually don't exist.
fd sounds more like file descriptions.
prop doesn't sound like a file at all.
Leftovers from failed transactions etc. should not change that property.
It's the same as BaseCollection.has
If vobject can't parse a component it raises an exception, but the filename of that component is missing in the logs.
If someone uploads a file that starts or ends with the chars {}, all REPORT requests on that collection will fail and it's impossible to delete the file.
@pbiering pbiering mentioned this pull request Oct 9, 2016
@liZe liZe merged commit 03fbb1e into Kozea:master Feb 26, 2017
@liZe
Copy link
Member

liZe commented Feb 26, 2017

Thanks a lot!

@Unrud Unrud deleted the storage branch June 4, 2017 16:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants