-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
fix bug on upload file name #5571
Conversation
Codecov Report
@@ Coverage Diff @@
## master #5571 +/- ##
==========================================
- Coverage 37.55% 37.55% -0.01%
==========================================
Files 321 321
Lines 47192 47206 +14
==========================================
+ Hits 17723 17728 +5
- Misses 26924 26931 +7
- Partials 2545 2547 +2
Continue to review full report at Codecov.
|
Hmm... This maps "abc/../../def" to "abc/def" and doesn't really obey most filesystem semantics - this might break a virtual filesystem interpretation. Would it be better applying the path to its own virtual root eg. "abc/../../def" -> "../def" -> "def" instead? |
Setting this as blocked just because I do have a few thoughts about what @zeripath raised. While I am fine with the logic as it is right now, I think what @zeripath would be an improvement. I believe this because of the following https://play.golang.org/p/FIhECabR29W is how pure golang handles things, and I believe we should align with them, so there is no suprise between projects. Of course, as always, my opinion is mine, and I am ok if others feel differently so please feel free to ignore this comment if you feel that way. |
If we do:
and perhaps
I guess that on windows we need to a little more to deal with its different separator? |
@zeripath not sure that |
@techknowlogick that's what the leading
|
OK, thinking on. I think we should do:
I would guess that it's OK in general to disallow any use of backslash in uploaded filenames for every OS. There will be some other paths that should be disallowed on Windows, for example COM LPT etc... See https://en.wikipedia.org/wiki/Filename for reserved words, characters etc. I just don't know whether we need to actually look at these. |
It may be worth looking at the impact of being able to inject a .git directory if there is a submodule for this repo (instead of just searching for it in the prefix) |
Hmm... I guess the point is to protect the server not the downstream user. Remember in order to upload they can commit. Now actually come to think of it I'm not certain why we're protecting the .git directory - we shouldn't actually be writing out a file to the repository rather, a commit to the repository so if someone wants to ruin their own repo then so be it. If we're actually writing out files under these addresses I'm a bit confused as it's clearly inefficient, similarly if we're ever reading out files without cleaning their path properly the issue isn't in the upload but in the reading part of the UI The reason I say this is because if the issue is that we read files we shouldn't in UI it should be possible to commit a sufficiently weird repository that would replicate the bad upload process. |
The problem is that currently, the repo is cloned based on the repo_id, so you can create a file named .git/hooks/pre-commit and since it's not executable, no one will be able to upload a file (via the frontend) to this repository until the hook gets cleaned up. |
Ok. This whole section of code needs thoroughly rethinking. Cloning isn't and shouldn't be necessary to do this, bozaro/git-as-svn doesn't do that and it's converting from the SVN protocol to git on the fly. @techknowlogick I'm happy for the current workaround to go in for now as we shouldn't leave this hole open any longer. I will actually have to have a closer look at this code and figure out what is going on. There's likely to be a lot more problems here - not least with LFS. @snyff do me a favour and try committing a repository with a file that has backslashes in it. A Linux based git should be happy with this file but I'm highly suspicious that gitea is going to do something bad. |
I wasn't able to get access to a Windows VM to test the above workaround, so I will merge as is. |
No worries, I think I've established that this whole area of code needs rewriting. |
backported to release/v1.6 in #5573 |
But somebody may put a test git repo on the git repo. So I think that should be allowed. |
should fix #5569