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.

[stale]

This issue has been automatically closed because of inactivity. You can re-open it if needed.

[lesderid]

Was this fixed? If not, it should be. This is a valid bug and some security standards/guidelines could require user data being on a noexec mount.

(I have wasted many an hour on trying to debug why some software doesn't work, finally figuring out that it's (silently) failing on a noexec mount. If you don't want to support it, at least give the user an actionable error message.)

[Ulrar]

Not that I'm aware of, unfortunately. We just change the flag in the SQLite manually after the first push, as far as I can tell everything works fine on a noexec partition except that very specific thing.

…

On Fri, Jun 14, 2019, 12:32 Les De Ridder ***@***.***> wrote: Was this fixed? If not, it should be. This is a valid bug and some security standards/guidelines could require user data being on a noexec mount. (I have wasted many an hour on trying to debug why some software doesn't work, finally figuring out that it's (silently) failing on a noexec mount. If you don't want to support it, at least give the user an actionable error message.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1231?email_source=notifications&email_token=AAGVHT3PQCPOOH6AZP5SXRLP2N6TRA5CNFSM4DDKYJM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXWQXEA#issuecomment-502074256>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGVHTZQG5QODKQIDHWELRTP2N6TRANCNFSM4DDKYJMQ> .

[zeripath]

Hmm... so I have an idea for how to go about ameliorating this.

I think setting https://git-scm.com/docs/git-config#Documentation/git-config.txt-corehooksPath in the gitea user .gitconfig would allow you to change the location of the git hooks for all repos.

You'd lose per repository git hooks but you should be able to set this up correctly so that gitea hooks can be run.

I think through clever use of this you could actually workaround the noexec problem entirely.

Now we could add a gitea workaround based on this - but it may be quite complex and I would have to think about how to make it work.

[lunny]

If this is a deployment problem, I think we can close this.

[lesderid]

@techknowlogick Was this fixed?

[techknowlogick]

It's not a bug, we need to be able to execute git hooks.

[Ulrar]

It's not a bug but an option to specify a different path for hooks would be a nice fix imho

…

On Wed 9 Dec 2020, 03:05 techknowlogick, ***@***.***> wrote: It's not a bug, we need to be able to execute git hooks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1231 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGVHTZPUFKMONLM6CA62NTST3SP5ANCNFSM4DDKYJMQ> .

[zeripath]

Undoubtedly something could be done using the config value core.hookspath https://git-scm.com/docs/git-config#Documentation/git-config.txt-corehooksPath and by making gitea hook pre-receive & gitea hook post-receive execute any hooks directly in pre-receive.d/ post-receive.d/ folders. (gitea hook update could be included here but I think we should stop providing this expensive and poorly implemented hook.) There may yet be potential difficulties with such an approach but I think it should be possible.

I would however say this is not a high priority - even though if implemented correctly it could be a considered a security improvement as the security benefits would be somewhat minor.

If you are desperate for this functionality and cannot provide a PR, you could either provide a bounty for the feature, or try contacting one of the maintainers - myself included - on discord directly asking one of us to implement it as a paid feature. I will likely get round to trying the approach listed above at some point but I'm quite busy on other things at present.