Gitea requires "exec" mounted repositories: Pushing to uninitialized repository on partition mounted with "noexec" silently fails

[pmattern]

• Gitea version (or commit ref): f0efb61
• Git version: 2.12.0
• Operating system: Arch Linux x86_64
• Database (use [x]):
  • PostgreSQL 9.6.1
  • MySQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant

Description

When the Git repositories handled by a Gitea instance happen to reside on a partition which is mounted with noexec set and a repository is not initialized upon creation from the Web-UI ("Initialize this repository with selected files and template" unchecked), the usual git push -u to populate the repository silently fails. That is, everything is fine according to the command line, but the repository remains empty in Gitea's Web-UI.
The problem is not that straight-forward to understand as the Gitea logs do not provide any hint.

To reproduce install current Gitea from scratch making sure the Git repositories in terms of [repository] - ROOT of app.ini are on a partition which is mounted with noexec set, have an arbitrary user create an uninitialized repository from within Gitea and have him populate that repository by running git push -u from CLI as usual.
Optionally repeat these steps after remounting the partition with exec set.

[pgaskin]

Is the log level set to Trace?

[pmattern]

Yes. Still there are only messages like

2017/03/12 23:09:20 [D] Session ID: a1831[...]
2017/03/12 23:09:20 [D] CSRF Token: ksKAq[...]
2017/03/12 23:09:20 [D] Bare repository: /<user>/<repo>
2017/03/12 23:09:20 [D] Template: repo/bare

in gitea.log while no error messages can be seen in the rather verbose xorm.log.

[pgaskin]

Can you strace gitea and post the output?

strace -o strace_gitea.out gitea web

[pmattern]

I ran strace but I fear it is of no use either. All entries are dealing with launch and shutdown only, all parts in between including pushing to the repository are missing completely.

As a side-effect the problem does not exist when Gitea is run as root (sudo strace -o /usr/share/gitea/log/strace.log /usr/share/gitea/gitea web), while it could be seen when it was run as the regular Git user via strace (sudo -u git strace -t -o /usr/share/gitea/log/strace.log /usr/share/gitea/gitea web) as well.

Current tests performed with 8746fb3.

[andreipoe]

Hi,

I'm experiencing the same issue with Gitea 1.1.1 running in Docker on AArch64. I wanted to add that pulling from such a repository is fine, the code is just not displayed in the web UI as if the repo was empty.

[bkcsoft]

The git-hooks required to update the DB can't be executed (noexec...) hence they fail. One possible solution would be to just have the hooks as symlinks to a gitea-directory. And have a pre-flight check when creating the repo that we can infact execute stuff in there.

[Ulrar]

So, how do we work around this in the meantime ? Where is the directory containing those hooks we'd need to move to a different partition ?

[lafriks]

@Ulrar you can not use partition with noexec partition to store git repositories

[Ulrar]

You very much can, it works fine. The only issue is that hook, which should be solved by moving it to a different partition with exec enabled and symlinking it to it's old location. That's what I do with payment binaries for websites, and it works fine, no reason it wouldn't with git

[lafriks]

@Ulrar git (independently of gitea) does not support storing hooks outside of repository folder and are stored in .git/hooks directory

[bkcsoft]

https://git-scm.com/docs/githooks#_description

By default the hooks directory is $GIT_DIR/hooks, but that can be changed via the core.hooksPath configuration variable

This would have to inject []string{"-c", "core.hooksPath=/path/to/gitea/lib/hooks/"} 🤔

gitea/cmd/serv.go

Lines 305 to 311 in 7a30208

	var gitcmd *exec.Cmd
	verbs := strings.Split(verb, " ")
	if len(verbs) == 2 {
	gitcmd = exec.Command(verbs[0], verbs[1], repoPath)
	} else {
	gitcmd = exec.Command(verb, repoPath)
	}

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.