blob: e7f3c6925973a0b872a29d3a16de933fba4bf30b (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
1. We have a `$srcdir/writable/page.mdwn` source file in Git.
2. ikiwiki is configured to allow edits via the CGI in `writable/*`,
but nowhere else.
2. Modify `$srcdir/writable/page.mdwn`, commit ⇒ commit `$id`.
3. `git mv $srcdir/writable/page.mdwn $srcdir/read-only/page.mdwn`
⇒ The web interface allows reverting commit `$id` (presumably because
it changes files only in `$srcdir/writable`). This operation
effectively modifies `$srcdir/read-only/page.mdwn`, which feels wrong.
My guess is that `check_canchange` does not take into account that Git
will automatically detect that the file affected by the to-be-reverted
commit has moved, and modify the file in its new location
when reverting.
> Working on it. In future please report non-public security
> vulnerabilities (such as authorization bypass) by private email to the
> maintainers, so that they are not visible to the general public
> until we have had a chance to fix the bug. --[[smcv]]
>> Sorry about that, I should clearly know better :/ --[[intrigeri]]
> Fixed by using
> `git revert --strategy=recursive --strategy-option=no-renames`.
> I tried to do something more clever (doing the revert, and checking
> whether it made changes that aren't allowed) but couldn't get it to
> work in a reasonable time, so I'm going with the simpler fix.
> [[Fix committed|done]], a release will follow later today.
>
> [[!cve CVE-2016-10026]] has been assigned to this vulnerability.
> --[[smcv]]
>> You rock, thanks a lot! --[[intrigeri]]
|