Description
Description
Based on my ad-hoc testing of the gitea dump command, I think the expected behaviour is that the default dump file created by the tool is supposed to be put in the current working folder. One way I found this out was that, while I was testing various options trying to get the dump tool to work (see #27423) I had changed directories into the config folder for gitea before running the dump operation:
cd /var/snap/gitea/common/conf
gitea dump
After waiting for a few minutes for the dump to complete, which was much longer than any of my previous attempts, I started to notice the performance of my system was starting to slow down. Closer examination of the memory, cpu and disk space showed that the dump was consuming tremendous amounts of resources. So I killed the dump operation and looked in the current working folder - there was a zip file there generated by the dump but it was many GB in size ... many times larger than the entire working folder for gitea.
What I think happened in this case is that the dump operation started creating the zip file in the config folder, but then it indexed the contents of the folder, picked up the backup file itself, and then tried to re-compress the file into the zip file, in an infinite recursion sort of way.
If I am correct, this is a rather nasty bug that could lead the system into a crash state fairly easily. It may even been abused as a potential exploit for a DoS type attack. Either way it probably should get fixed.
Gitea Version
Gitea version 1.20.5 built with GNU Make 4.3, go1.21.1 : bindata, sqlite, sqlite_unlock_notify, pam, cert
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
git version 2.34.1
Operating System
Ubuntu 22.04.3 LTS
How are you running Gitea?
From the console
Database
SQLite