github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

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

New Issue
Closed
opened 2025-11-02 03:25:08 -06:00 by GiteaMirror · 21 comments
GiteaMirror commented 2025-11-02 03:25:08 -06:00
Owner
Copy Link

Originally created by @pmattern on GitHub (Mar 12, 2017).

  • Gitea version (or commit ref): f0efb615
  • 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.

Originally created by @pmattern on GitHub (Mar 12, 2017). - Gitea version (or commit ref): f0efb615 - Git version: 2.12.0 - Operating system: Arch Linux x86_64 - Database (use `[x]`): - [x] PostgreSQL 9.6.1 - [ ] MySQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] 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" *un*checked), 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.
GiteaMirror added the topic/deployment label 2025-11-02 03:25:08 -06:00
GiteaMirror commented 2025-11-02 03:25:09 -06:00
Author
Owner
Copy Link

@pgaskin commented on GitHub (Mar 12, 2017):

Is the log level set to Trace?

@pgaskin commented on GitHub (Mar 12, 2017): Is the log level set to Trace?
GiteaMirror commented 2025-11-02 03:25:09 -06:00
Author
Owner
Copy Link

@pmattern commented on GitHub (Mar 12, 2017):

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.

@pmattern commented on GitHub (Mar 12, 2017): 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`.
GiteaMirror commented 2025-11-02 03:25:09 -06:00
Author
Owner
Copy Link

@pgaskin commented on GitHub (Mar 12, 2017):

Can you strace gitea and post the output?

strace -o strace_gitea.out gitea web

@pgaskin commented on GitHub (Mar 12, 2017): Can you strace gitea and post the output? `strace -o strace_gitea.out gitea web`
GiteaMirror commented 2025-11-02 03:25:10 -06:00
Author
Owner
Copy Link

@pmattern commented on GitHub (Mar 14, 2017):

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 8746fb33.

@pmattern commented on GitHub (Mar 14, 2017): 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 8746fb33.
GiteaMirror commented 2025-11-02 03:25:10 -06:00
Author
Owner
Copy Link

@andreipoe commented on GitHub (May 28, 2017):

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.

@andreipoe commented on GitHub (May 28, 2017): 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.
GiteaMirror commented 2025-11-02 03:25:10 -06:00
Author
Owner
Copy Link

@bkcsoft commented on GitHub (Jun 15, 2017):

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.

@bkcsoft commented on GitHub (Jun 15, 2017): 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.
GiteaMirror commented 2025-11-02 03:25:10 -06:00
Author
Owner
Copy Link

@Ulrar commented on GitHub (Jul 25, 2018):

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 ?

@Ulrar commented on GitHub (Jul 25, 2018): 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 ?
GiteaMirror commented 2025-11-02 03:25:11 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Jul 25, 2018):

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

@lafriks commented on GitHub (Jul 25, 2018): @Ulrar you can not use partition with noexec partition to store git repositories
GiteaMirror commented 2025-11-02 03:25:11 -06:00
Author
Owner
Copy Link

@Ulrar commented on GitHub (Jul 25, 2018):

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

@Ulrar commented on GitHub (Jul 25, 2018): 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
GiteaMirror commented 2025-11-02 03:25:11 -06:00
Author
Owner
Copy Link

@lafriks commented on GitHub (Jul 25, 2018):

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

@lafriks commented on GitHub (Jul 25, 2018): @Ulrar git (independently of gitea) does not support storing hooks outside of repository folder and are stored in `.git/hooks` directory
GiteaMirror commented 2025-11-02 03:25:11 -06:00
Author
Owner
Copy Link

@bkcsoft commented on GitHub (Jul 26, 2018):

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/"} 🤔

7a30208e05/cmd/serv.go (L305-L311)

@bkcsoft commented on GitHub (Jul 26, 2018): 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/"}` :thinking: https://github.com/go-gitea/gitea/blob/7a30208e05d202062f8ca74c2637273d8bc23a77/cmd/serv.go#L305-L311
GiteaMirror commented 2025-11-02 03:25:12 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Jan 16, 2019):

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[bot] commented on GitHub (Jan 16, 2019): 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.
GiteaMirror commented 2025-11-02 03:25:12 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Feb 19, 2019):

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

@stale[bot] commented on GitHub (Feb 19, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.
GiteaMirror commented 2025-11-02 03:25:12 -06:00
Author
Owner
Copy Link

@lesderid commented on GitHub (Jun 14, 2019):

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.)

@lesderid commented on GitHub (Jun 14, 2019): 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.)
GiteaMirror commented 2025-11-02 03:25:13 -06:00
Author
Owner
Copy Link

@Ulrar commented on GitHub (Jun 14, 2019):

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 notifications@github.com 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
https://github.com/go-gitea/gitea/issues/1231?email_source=notifications&email_token=AAGVHT3PQCPOOH6AZP5SXRLP2N6TRA5CNFSM4DDKYJM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXWQXEA#issuecomment-502074256,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGVHTZQG5QODKQIDHWELRTP2N6TRANCNFSM4DDKYJMQ
.

@Ulrar commented on GitHub (Jun 14, 2019): 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 <notifications@github.com> 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 > <https://github.com/go-gitea/gitea/issues/1231?email_source=notifications&email_token=AAGVHT3PQCPOOH6AZP5SXRLP2N6TRA5CNFSM4DDKYJM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXWQXEA#issuecomment-502074256>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAGVHTZQG5QODKQIDHWELRTP2N6TRANCNFSM4DDKYJMQ> > . >
GiteaMirror commented 2025-11-02 03:25:13 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jun 15, 2019):

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.

@zeripath commented on GitHub (Jun 15, 2019): 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.
GiteaMirror commented 2025-11-02 03:25:13 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Oct 15, 2020):

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

@lunny commented on GitHub (Oct 15, 2020): If this is a deployment problem, I think we can close this.
GiteaMirror commented 2025-11-02 03:25:13 -06:00
Author
Owner
Copy Link

@lesderid commented on GitHub (Dec 9, 2020):

@techknowlogick Was this fixed?

@lesderid commented on GitHub (Dec 9, 2020): @techknowlogick Was this fixed?
GiteaMirror commented 2025-11-02 03:25:14 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (Dec 9, 2020):

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

@techknowlogick commented on GitHub (Dec 9, 2020): It's not a bug, we need to be able to execute git hooks.
GiteaMirror commented 2025-11-02 03:25:14 -06:00
Author
Owner
Copy Link

@Ulrar commented on GitHub (Dec 9, 2020):

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, notifications@github.com 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
https://github.com/go-gitea/gitea/issues/1231#issuecomment-741495859,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGVHTZPUFKMONLM6CA62NTST3SP5ANCNFSM4DDKYJMQ
.

@Ulrar commented on GitHub (Dec 9, 2020): 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, <notifications@github.com> 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 > <https://github.com/go-gitea/gitea/issues/1231#issuecomment-741495859>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAGVHTZPUFKMONLM6CA62NTST3SP5ANCNFSM4DDKYJMQ> > . >
GiteaMirror commented 2025-11-02 03:25:14 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Dec 9, 2020):

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.

@zeripath commented on GitHub (Dec 9, 2020): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label topic/deployment
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#485
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?