Pushing to empty repository is not reflected in web UI

[kauron]

• Gitea version (or commit ref): 1.10.2
• Git version: 2.25.0
• Operating system: ArchLinuxARM
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No: https://try.gitea.io/mxt92822/empty_test
  • Not relevant
• Log gist: https://gist.github.com/kauron/136587e6abf7611481d7461000eb8c4d

Description

Exactly the same as in #9365, but the filesystem is mounted with exec. I think the localhost API calls are the hooks, but I'm not sure. The hooks in the repo run properly when executed manually through the terminal.

(description copied from the previously mentioned issue)

I created a new repo and pushed a local repository. I tried it both with --all (it has two branches) and without (pushed only master). Either way the repository is not changed to non-empty. I did it manually in the DB to set the is_empty column to 0 which fixed the problem.

[zeripath]

I can't see any calls to pre-receive or post-receive so they're clearly not running.

My suspicion is that your Gitea repositories hooks have lost their executable bit. That means for example not just the files inside pre-receive.d but pre-receive itself

The other possibility is that they're out of date.

What do you mean by saying that they run find when executed from the terminal? Have you managed to properly spoof a pre-receive command?

---

After a very long time and plenty of scratching of heads it appears the likely solution is:

#9792 (comment)

[kauron]

My suspicion is that your Gitea repositories hooks have lost their executable bit. That means for example not just the files inside pre-receive.d but pre-receive itself

This is the output of ls -lh hooks/ inside one of the gitea repos:

total 76K
-rwxr-xr-x 1 gitea gitea  478 Jan 15 22:44 applypatch-msg.sample
-rwxr-xr-x 1 gitea gitea  896 Jan 15 22:44 commit-msg.sample
-rwxr-xr-x 1 gitea gitea 3.1K Jan 15 22:44 fsmonitor-watchman.sample
-rwxr-xr-x 1 gitea gitea  303 Jan 15 22:44 post-receive
drwxr-xr-x 2 gitea gitea 4.0K Jan 15 22:44 post-receive.d
-rwxr-xr-x 1 gitea gitea  189 Jan 15 22:44 post-update.sample
-rwxr-xr-x 1 gitea gitea  424 Jan 15 22:44 pre-applypatch.sample
-rwxr-xr-x 1 gitea gitea 1.6K Jan 15 22:44 pre-commit.sample
-rwxr-xr-x 1 gitea gitea  416 Jan 15 22:44 pre-merge-commit.sample
-rwxr-xr-x 1 gitea gitea 1.5K Jan 15 22:44 prepare-commit-msg.sample
-rwxr-xr-x 1 gitea gitea 1.4K Jan 15 22:44 pre-push.sample
-rwxr-xr-x 1 gitea gitea 4.8K Jan 15 22:44 pre-rebase.sample
-rwxr-xr-x 1 gitea gitea  303 Jan 15 22:44 pre-receive
drwxr-xr-x 2 gitea gitea 4.0K Jan 15 22:44 pre-receive.d
-rwxr-xr-x 1 gitea gitea  544 Jan 15 22:44 pre-receive.sample
-rwxr-xr-x 1 gitea gitea  283 Jan 15 22:44 update
drwxr-xr-x 2 gitea gitea 4.0K Jan 15 22:44 update.d
-rwxr-xr-x 1 gitea gitea 3.6K Jan 15 22:44 update.sample

The other possibility is that they're out of date.

How could I check that/update them?

What do you mean by saying that they run find when executed from the terminal? Have you managed to properly spoof a pre-receive command?

In the other issue, the ability of the server's user to execute the hooks was disabled, so I logged in as the gitea user and manually executed one of the hooks (successfully). I'd already checked that they were executable, but wanted to make sure I was reading the permissions properly.

[zeripath]

OK so those are all appropriately executable, next could you check the contents and mode of pre-receive.d/gitea

To update/correct these you need to use the administrator task "Update and resynchronize hooks"

[kauron]

Contents and mode:

[gitea@host pre-receive.d]$ ls -lh
total 4.0K
-rwxr-xr-x 1 gitea gitea 84 ene 15 22:44 gitea
[gitea@host pre-receive.d]$ cat gitea
#!/usr/bin/env bash
"/usr/bin/gitea" hook --config='/etc/gitea/app.ini' pre-receive

After running the corresponding administrator task, the only thing that changes is the time attribute of the file.

The pre-receive hook seems to be the default:

#!/usr/bin/env bash
data=$(cat)
exitcodes=""
hookname=$(basename $0)
GIT_DIR=${GIT_DIR:-$(dirname $0)}

for hook in ${GIT_DIR}/hooks/${hookname}.d/*; do
test -x "${hook}" || continue
echo "${data}" | "${hook}"
exitcodes="${exitcodes} $?"
done

for i in ${exitcodes}; do
[ ${i} -eq 0 ] || exit ${i}
done

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[kauron]

This issue is still valid.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[kauron]

This issue is still valid. @zeripath, what additional info can I provide to help debug this?

[zeripath]

Hmm... I'm a bit stumped but, one thing I've noticed elsewhere: make sure your LFS_CONTENT_PATH is an absolute path. (I wonder if you're affected by the thing that #11362 fixes)

[kauron]

It was a relative path. I've changed it to an absolute path, restarted gitea and tried again, but the problem's still there.

[zeripath]

What version of gitea are you using? - Would it be possible to update to master (preferably) or 1.11.5?

[kauron]

I'm using 1.11.5, but I'll try to get the master branch up and running.

[kauron]

I have tried executing v1.11.5 in a x86_64 PC. Then I tried in the same ARM machine where it fails, running a separate instance under a different user with a blank db and the existing db. I could not reproduce the issue in either case.

While checking the logs, I've found the following:

may 26 16:31:08 HOSTNAME gitea[10611]: 2020/05/26 16:31:08 ...eue/queue_wrapped.go:68:setInternal() [W] [Attempt: 7] Failed to create queue: level for  cfg: [123 34 65 100 100 114 101 115 115 101 115 34 58 34 49 50 55 46 48 46 48 46 49 58 54 51 55 57 34 44 34 66 97 116 99 104 76 101 110 103 116 104 34 58 50 48 44 34 66 108 111 99 107 84 105 109 101 111 117 116 34 58 49 48 48 48 48 48 48 48 48 48 44 34 66 111 111 115 116 84 105 109 101 111 117 116 34 58 51 48 48 48 48 48 48 48 48 48 48 48 44 34 66 111 111 115 116 87 111 114 107 101 114 115 34 58 53 44 34 68 66 73 110 100 101 120 34 58 48 44 34 68 97 116 97 68 105 114 34 58 34 100 97 116 97 47 100 97 116 97 47 113 117 101 117 101 115 47 116 97 115 107 34 44 34 77 97 120 87 111 114 107 101 114 115 34 58 49 48 44 34 78 97 109 101 34 58 34 116 97 115 107 34 44 34 78 101 116 119 111 114 107 34 58 34 34 44 34 80 97 115 115 119 111 114 100 34 58 34 34 44 34 81 117 101 117 101 76 101 110 103 116 104 34 58 50 48 44 34 81 117 101 117 101 78 97 109 101 34 58 34 116 97 115 107 95 113 117 101 117 101 34 44 34 87 111 114 107 101 114 115 34 58 49 125] error: leveldb: manifest corrupted (field 'comparer'): missing [file=MANIFEST-708535]
may 26 16:31:08 HOSTNAME gitea[10611]: 2020/05/26 16:31:08 ...eue/queue_wrapped.go:68:setInternal() [W] [Attempt: 7] Failed to create queue: level for  cfg: [123 34 65 100 100 114 101 115 115 101 115 34 58 34 49 50 55 46 48 46 48 46 49 58 54 51 55 57 34 44 34 66 97 116 99 104 76 101 110 103 116 104 34 58 50 48 44 34 66 108 111 99 107 84 105 109 101 111 117 116 34 58 49 48 48 48 48 48 48 48 48 48 44 34 66 111 111 115 116 84 105 109 101 111 117 116 34 58 51 48 48 48 48 48 48 48 48 48 48 48 44 34 66 111 111 115 116 87 111 114 107 101 114 115 34 58 53 44 34 68 66 73 110 100 101 120 34 58 48 44 34 68 97 116 97 68 105 114 34 58 34 100 97 116 97 47 100 97 116 97 47 113 117 101 117 101 115 47 105 115 115 117 101 95 105 110 100 101 120 101 114 34 44 34 77 97 120 87 111 114 107 101 114 115 34 58 49 48 44 34 78 97 109 101 34 58 34 105 115 115 117 101 95 105 110 100 101 120 101 114 34 44 34 78 101 116 119 111 114 107 34 58 34 34 44 34 80 97 115 115 119 111 114 100 34 58 34 34 44 34 81 117 101 117 101 76 101 110 103 116 104 34 58 50 48 44 34 81 117 101 117 101 78 97 109 101 34 58 34 105 115 115 117 101 95 105 110 100 101 120 101 114 95 113 117 101 117 101 34 44 34 87 111 114 107 101 114 115 34 58 49 125] error: leveldb: manifest corrupted (field 'comparer'): missing [file=MANIFEST-708536]

This message is repeated periodically, every 90 seconds approx.

Another message that I'm not sure whether or not is related is the following line when pushing the repo:

remote: Processed 0 references in total

a similar line appeard in the cases when it worked properly, but instead of 0 references, it was 1 reference, or it didn't appear at all.

[zeripath]

OK so that's a problem with the queues - they have been corrupted due to a crash or a kill -9 at some point. You will need to remove them.

[kauron]

So do I need to delete the two folders called task and issue_indexer in $GITEA_HOME/data/data/queues/?

I did so, and the log message stopped appearing, but the issue still occurs.

[ltguillaume]

I have walked through this issue and I'm in the exact same boat (and have been for months), except for the queue issue of #9792 (comment).

I'm giving some extra info, may not be relevant, but perhaps something pops up.

• Raspberry Pi 4
• Arch Linux for ARM
• Gitea 1.11.5
• Only using this in my local network, so I haven't (yet) set up an SSL certificate, i.e. communication is unencrypted and directly to the Pi's IP.
• System root on SSD, repos are on separate mount:

[repository]
ROOT = /srv/git

(where /srv is not a directory but a mounted partition)

/etc/systemd/system/gitea.service.d/override.conf:

[Service]
ReadWritePaths=/etc/gitea/app.ini /srv/git

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[ltguillaume]

This issue still hasn't been addressed and basically means I have to do a manual SQL queryy every time I create a new repo.

[zeripath]

This problem is always due to users not pushing with a key managed by Gitea.

The only way Gitea knows about commits is if it is told about them during post-receive - to do that there is a post receive hook in the repository and that requires an environment which is set up by Gitea serv or the web server.

I will not go in to how to set the environment correctly because that is unsupported - but it is not difficult to find what the environment should be. Only push to Gitea's repositories using a Gitea managed key or over http.

[zeripath]

@ltguillaume Ok, let's look at your case. You're definitely pushing to gitea's http url? Are you post-receive hooks present and executable? Are they up-to-date?

[ltguillaume]

I'm always using http://myserver:3000/ltGuillaume/Repo-Name.git, yes, but I probably should be doing something more. I'm not sure what post-receive hooks I should create. I usually do the following, after creating an empty repo from the Gitea web interface:

git init
git add .
git commit
git remote add origin http://myserver:3000/ltGuillaume/Repo-Name.git
git push -u origin master

[zeripath]

In your app.ini there is a [repository] section. That has a setting ROOT which says where the raw git repositories that Gitea uses are kept.

Your repositories are stored in directories under that ROOT called owner/reponame.git

In each, there is a hooks/ directory. In particular there are 4 special scripts in these pre-receive,pre-receive.d/gitea, post-receive, post-receive.d/gitea.

These need to be executable and run each time a push is made.

Gitea will create these "delegate" hooks for you. There is a function on the http://localhost:3000/admin page: Resynchronize pre-receive, update and post-receive hooks of all repositories - that will update the content for these. However, if your repositories are on a non-executable partition that would cause problems.

It is worth checking the values of these files.

[ltguillaume]

The partition containing my repos is mounted using defaults,noatime,nodiratime,discard, so there's no noexec there.

The pre- and post-receive.d hook folders and the gitea files within them are present and have the permissions (d)rwxr-xr-x.

I just created a new repo via the web interface without initializing it and went into its post-receive.d and and pre-receive.d folders: both had a gitea file with:

#!/usr/bin/env bash
"/usr/bin/gitea" hook --config='/etc/gitea/app.ini' [pre/post]-receive

The files pre-receive and post-receive were also present, here the contents of one:

#!/usr/bin/env bash
data=$(cat)
exitcodes=""
hookname=$(basename $0)
GIT_DIR=${GIT_DIR:-$(dirname $0)}

for hook in ${GIT_DIR}/hooks/${hookname}.d/*; do
test -x "${hook}" && test -f "${hook}" || continue
echo "${data}" | "${hook}"
exitcodes="${exitcodes} $?"
done

for i in ${exitcodes}; do
[ ${i} -eq 0 ] || exit ${i}
done

[zeripath]

Sorry I haven't replied today. Your findings above definitely indicate that the messages git should be sending are not getting through to the bash hooks.

Now that is weird. So the question is what is to blame.

Well one thing you could do - just to rule out one last way Gitea could be to blame - is to simplify and remove most of the restrictions on the authorized key line in .authorized_keys but I don't think that will fix things.

My suspicion is that it is bash on the server or it is a the version of git that is on the server.

But how do you figure out?

One option is to try to upgrade these to see if that fixes it. Another is to seek help on arch. Explain that hooks are receiving no content on stdin on pushing. They might know what the problem is.

[ltguillaume]

Well one thing you could do - just to rule out one last way Gitea could be to blame - is to simplify and remove most of the restrictions on the authorized key line in .authorized_keys but I don't think that will fix things.

I'm using HTTP to push my commits, so will authorized_keys even have any influence?

My suspicion is that it is bash on the server or it is a the version of git that is on the server.
But how do you figure out?
One option is to try to upgrade these to see if that fixes it. Another is to seek help on arch. Explain that hooks are receiving no content on stdin on pushing. They might know what the problem is.

Everything is up-to-date, and I'm using a rolling release distro (Arch), so it's more up-to-date than most other distros already.
git: 2.28.0
bash: 5.0.018 (also had these isssues with bash 4.x)

I just tried cloning, then committing some changes to an affected repo by using Git on the server itself. Result's the same:

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 299 bytes | 299.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Pre-Receive hook...
remote:
remote: End
remote: Update hook...
remote:
remote: End
remote: Post-Receive hook...
remote: RECEIVED
remote:
remote: END
remote: End
remote: Processed 0 references in total
To http://localhost:3000/ltGuillaume/MyProject.git
   76a202c..e8533d5  master -> master

I'll create a topic on https://archlinuxarm.org/forum/ and I'll try Gitea on my Manjaro virtual machine, just to be sure it's not a cross-platform Arch issue (I highly doubt it).

Edit: Ok, in Manjaro, the correct behavior with the script from #9792 (comment) resulted in

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 259 bytes | 259.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote: RECEIVED
remote: d55828af5c0b4f64966368def180496530ac6603 c1ca110e76cc2a4f27b9909e926802e60a66cc0b refs/heads/master
remote: END
remote: Processed 0 references in total
To http://localhost:3000/ltGuillaume/MyProject.git
   d55828a..c1ca110  master -> master

[zeripath]

I wonder what's happening on Arch then. How weird.

[techknowlogick]

FWIW I'm using manjaro on a pinebook pro (aarch64) and I'm unable to replicate.

[ltguillaume]

I guess I got 1 step closer with the following (this must be a recent addition, I've checked the Wiki multiple times, obviously).

Edit: user Simplefied has added this workaround to the Arch Wiki on June 6th (https://wiki.archlinux.org/index.php?title=Gitea&type=revision&diff=618524&oldid=615095).

Process dumped core on ArchLinux ARM

A problem can appear after pushing new repo. In web UI repo stay uninitialized, and the following error is present in the system journal:

Jun 06 14:34:20 rpi-srv systemd-coredump[5724]: Process 5722 (cat) of user 986 dumped core.
                                                Stack trace of thread 5722:
                                                #0  0x0000000076f06e58 posix_fadvise64 (libc.so.6 + 0xd2e58)

To fix this problem, override gitea.service:
# systemctl edit gitea

[Service]
SystemCallArchitectures=
SystemCallFilter=

This has changed the push output from:

remote: Pre-Receive hook...
remote:
remote: End
remote: Update hook...
remote:
remote: End
remote: Post-Receive hook...
remote: RECEIVED
remote:
remote: END
remote: End
remote: Processed 0 references in total

to

remote: Pre-Receive hook...
remote:
remote: End
remote: Update hook...
remote:
remote: End
remote: Post-Receive hook...
remote: RECEIVED
remote: e8533d5f096957a7d6298510aec9af8f89fb4e33 28f42c6f8275198abc5856307bd3d024e3759436 refs/heads/master
remote: END
remote: End
remote: Processed 0 references in total

It looks like this mean there are no issues with hook not getting the stdin contents anymore, but there are still no references processed.

[ltguillaume]

After recreating the repo (and thus removing the scripts), I finally got

remote: . Processing 1 references
remote: Processed 1 references in total

Every test since has consistently produced a working, fully initialized repo.

Thanks @zeripath for all your help. Sorry I didn't find the core dump myself. As you can see the dump is linked to cat, I didn't think to look for anything like that, I guess I should have after your script.

[zeripath]

Sorry it took so long. Maybe we need to drop the bash scripts and write some go to do it.

[ltguillaume]

I don't know. Now I found the solution, I'm seeing:

#6620 (comment) Definitely related, not officially resolved (closed by stalebot).

#11231 Seems like it's not yet resolved (closed by stalebot) and may have the same solution.

[zeripath]

OK so if you can write a clear solution in a comment here we can close this issue and add links to it on those issues.

[ltguillaume]

The following addition to the Arch Wiki has solved the following issues for me:

1. Newly created repos remain as if empty in web UI after pushing commits
2. Repo sizes remain 0B after manually setting repos those as non-empty
3. No repo updates on the Dashboard (Why recent commits of some repositories are not listed on the index page? #6620)

User Simplefied has added this workaround on June 6th (https://wiki.archlinux.org/index.php?title=Gitea&type=revision&diff=618524&oldid=615095).

Process dumped core on ArchLinux ARM

A problem can appear after pushing new repo. In web UI repo stay uninitialized, and the following error is present in the system journal:

Jun 06 14:34:20 rpi-srv systemd-coredump[5724]: Process 5722 (cat) of user 986 dumped core.
                                                Stack trace of thread 5722:
                                                #0  0x0000000076f06e58 posix_fadvise64 (libc.so.6 + 0xd2e58)

To fix this problem, override gitea.service:
# systemctl edit gitea

[Service]
SystemCallArchitectures=
SystemCallFilter=

[zeripath]

Thanks @ItGuillaume really sorry this took so long

[zeripath]

@ArchangeGabriel would you be able to add:

[Service]
SystemCallArchitectures=
SystemCallFilter=

to the systemd service file?

[ArchangeGabriel]

@zeripath I would prefer not, this is a security feature. First of all, it seems to only fail under ArchLinux ARM, so this should rather be changed there than in the standard Arch (ARM variant is a separate distro that sync most of our PKGBUILD but carry specfic changes). Then, it would be better to determine what should be allowed (see https://www.freedesktop.org/software/systemd/man/systemd.exec.html#System Call Filtering for documentation) rather than allowing everything.

[zeripath]

Fair enough.

Presumably the arch arm systemd has some default set for these values which is relatively restrictive - I guess we would need an arch user to play the whack-a-mole game to figure out what calls are actually needed.

I'll have a think about whether we can actually avoid these bash calls - I think if we restructure things slightly we should be able to do that. I'm not sure that would necessarily reduce the syscall problem - it might do and getting rid of the bash would likely be helpful anyway

[ltguillaume]

1. As far as I can tell, including SystemCallArchitectures= seems to be unnecessary. I don't know if it is recommended for other reasons, but it's not necessary for the workaround to do its job.
2. I already tried SystemCallFilter=+@set for all specified sets in the https://www.freedesktop.org/software/systemd/man/systemd.exec.html documentation, but that didn't do anything.
3. Then I compared the systemd-analyze syscall-filter output between Manjaro and Arch ARM and saw no differences of consequence:
   Manjaro showed

# Unlisted System Calls (supported by the local kernel, but not included in any of the groups listed above):
#   mincore
#   seccomp
#   syslog

where ARM showed an extra call faccessat2 in the set @file-system and an extra call cacheflush in the set @default. So I doubt there's anything to gain by specifically setting SystemCallFilter=+some_call, it might just be a bug.

callfilters-manjaro.txt
callfilters-pi.txt

[zeripath]

Is it possible that the cat binary is a different arm architecture binary so the issue is that systemd is preventing the call?

[ltguillaume]

Is it possible that the cat binary is a different arm architecture binary so the issue is that systemd is preventing the call?

I would think that in that case SystemCallArchitectures= would be necessary for the workaround to function. As stated before, it's not.

I copied over cat, here it is. It says ARM HF ABI:5, just like the gitea executable.
cat.zip

[ltguillaume]

Here's a very similar issue with havegd: https://archlinuxarm.org/forum/viewtopic.php?f=15&t=14549

[ltguillaume]

If I only add the following line (discarding SystemCallArchitecture= and SystemCallFilter=), pushing commits also works:

[Service]
SystemCallErrorNumber=EPERM

@ArchangeGabriel I suppose this would be preferable, right? Or does this imply the otherwise explicitly added SystemCallFilter= somehow? I couldn't find that in the documentation, so I'm guessing it doesn't.

------- Edit -------

This is what's in /usr/lib/systemd/system/gitea.service

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
After=mysqld.service
After=postgresql.service
After=memcached.service
After=redis.service

[Service]
User=gitea
Group=gitea
Type=simple
WorkingDirectory=~
RuntimeDirectory=gitea
LogsDirectory=gitea
StateDirectory=gitea
Environment=USER=gitea HOME=/var/lib/gitea GITEA_WORK_DIR=/var/lib/gitea
ExecStart=/usr/bin/gitea web -c /etc/gitea/app.ini
Restart=always
RestartSec=2s
CapabilityBoundingSet=
NoNewPrivileges=True
#SecureBits=noroot-locked
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/etc/gitea/app.ini
PrivateTmp=true
PrivateDevices=true
PrivateUsers=true
ProtectHostname=true
ProtectClock=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectKernelLogs=true
ProtectControlGroups=true
LockPersonality=true
MemoryDenyWriteExecute=true
RestrictRealtime=true
RestrictSUIDSGID=true
SystemCallArchitectures=native
SystemCallFilter=@system-service

[Install]
WantedBy=multi-user.target

So, no SystemCallErrorNumber was specified.

I added SystemCallErrorNumber=EPERM to the file, removed all the overrides and all worked fine.

So it seems we just need to get SystemCallErrorNumber=EPERM into gitea.service by default.

[zeripath]

@ltguillaume good thinking.

I think that could be added to our documentation too.

[ltguillaume]

I'm hoping this will get picked up https://bugs.archlinux.org/task/60669#comment192661 (it's assigned to @ArchangeGabriel)

@ArchangeGabriel Also, this bug indeed mentions that the current hardening isn't very restrictive at all: it uses the set @system-service, which is a rather large superset. If you/we could restrict it more specifically to gitea's tasks, the syscall hardening would be way more useful.

My thinking is, though, that on Arch ARM currently something is already not permitted around cat with the current @system-service syscall hardening, otherwise the SystemCallErrorNumber wouldn't have mattered.

[ltguillaume]

Great, looks like everything's implemented. The Wiki's been updated, too 👍