Using (ssh) git with full repo path and gitea authorized-keys fails with cryptical message (Unregistered owner: opt) #1396

New Issue

2025-11-02T03:59:30-06:00

GiteaMirror commented

2025-11-02 03:59:30 -06:00

Originally created by @MonsieurCellophane on GitHub (Dec 21, 2017).

Gitea version (or commit ref):
Git version: v1.3.2
Operating system: CentOS6.9
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

My git user has home /opt/git, and gitea repositories live under /opt/git/gitea-repositories

Under these circumstances and using the gitea rewritten authorized keys, cloning a repo with full path fails thusly:

$ git clone git@snafu.io:/opt/git/gitea-repositories/mrc/foo.git fubar
Gitea: Repository owner does not exist
Unregistered owner: opt
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

however using relative path succeeds:

 $ git clone git@snafu.io:mrc/foo.git fubar
Cloning into 'foo'...
X11 forwarding request failed on channel 0
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (4/4), done.
Checking connectivity... done.

This can be traced back to a place in cmds/serv.go, where the user name is computed taking the string from the beginning of the path to the first '/':


        rr := strings.SplitN(repoPath, "/", 2)
        if len(rr) != 2 {
                fail("Invalid repository path", "Invalid repository path: %v", args)
        }
        username := strings.ToLower(rr[0])

(on a side note, the splitting and taking the first 2 components of the path defeats the following length check)

Using a standard authorized_keys file suceeds with full path (but not, as expected, with a partial path).

Expected behavior is that absolute path should be recognised and transformed by removing the ROOT stem (as a boon, similar treatment could be given to paths relative to git's home form git@snafu.io:/opt/git/gitea-repositories/mrc/foo.git fubar). At the very least, a more useful error message should be given - e.g. "Absolute path unsupported. Please use paths relative to ROOT"

...

Screenshots

Originally created by @MonsieurCellophane on GitHub (Dec 21, 2017).  - Gitea version (or commit ref): - Git version: v1.3.2 - Operating system: CentOS6.9 - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description My git user has home /opt/git, and gitea repositories live under /opt/git/gitea-repositories Under these circumstances and using the gitea rewritten authorized keys, cloning a repo with full path fails thusly: ``` $ git clone git@snafu.io:/opt/git/gitea-repositories/mrc/foo.git fubar Gitea: Repository owner does not exist Unregistered owner: opt fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ``` however using relative path succeeds: ``` $ git clone git@snafu.io:mrc/foo.git fubar Cloning into 'foo'... X11 forwarding request failed on channel 0 remote: Counting objects: 4, done. remote: Compressing objects: 100% (3/3), done. remote: Total 4 (delta 0), reused 0 (delta 0) Receiving objects: 100% (4/4), done. Checking connectivity... done. ``` This can be traced back to a place in cmds/serv.go, where the user name is computed taking the string from the beginning of the path to the first '/': ``` rr := strings.SplitN(repoPath, "/", 2) if len(rr) != 2 { fail("Invalid repository path", "Invalid repository path: %v", args) } username := strings.ToLower(rr[0]) ``` (on a side note, the splitting and taking the first 2 components of the path defeats the following length check) Using a standard authorized_keys file suceeds with full path (but not, as expected, with a partial path). Expected behavior is that absolute path should be recognised and transformed by removing the ROOT stem (as a boon, similar treatment could be given to paths relative to git's home form git@snafu.io:/opt/git/gitea-repositories/mrc/foo.git fubar). At the very least, a more useful error message should be given - e.g. "Absolute path unsupported. Please use paths relative to ROOT" ... ## Screenshots

GiteaMirror added the type/question reviewed/wontfix labels 2025-11-02 03:59:30 -06:00

GiteaMirror closed this issue

2025-11-02 03:59:30 -06:00

GiteaMirror commented

2025-11-02 03:59:30 -06:00

@lunny commented on GitHub (Dec 21, 2017):

Why you need an absolute path?

@lunny commented on GitHub (Dec 21, 2017): Why you need an absolute path?

GiteaMirror commented

2025-11-02 03:59:31 -06:00

@MonsieurCellophane commented on GitHub (Dec 22, 2017):

@lunny Because for historical reasons I have several repos around, with mixed responsibility, which have an absolute path in their config. If I decide to stick with gitea I'll get around to change them eventually, but in the meantime I'd like them to keep working as is (with some sleight-of-symlinking-hand). If not, I will have to transition the repos as mirrors, or keep kicking gitea serv out of authorized-keys, which is too bad and a hassle to boot.

Regardless, the error message (Unregistered owner: opt), as it is, is nonsensical, and it took me 45 minutes to figure (and that is because the if len(rr) != 2 does not work). Besides, suppose that a /opt/git/gitea/opt/foo.git does actually exist (so that opt is registered user) maybe as a fork/mirror/import of the other one...

@MonsieurCellophane commented on GitHub (Dec 22, 2017): @lunny Because for historical reasons I have several repos around, with mixed responsibility, which have an absolute path in their config. If I decide to stick with gitea I'll get around to change them eventually, but in the meantime I'd like them to keep working as is (with some sleight-of-symlinking-hand). If not, I will have to transition the repos as mirrors, or keep kicking gitea serv out of authorized-keys, which is too bad and a hassle to boot. Regardless, the error message (_Unregistered owner: opt_), as it is, is nonsensical, and it took me 45 minutes to figure (and that is because the _if len(rr) != 2_ does not work). Besides, suppose that a /opt/git/gitea/opt/foo.git does actually exist (so that opt is registered user) maybe as a fork/mirror/import of the other one...

GiteaMirror commented

2025-11-02 03:59:31 -06:00

@lafriks commented on GitHub (Dec 22, 2017):

because just like in github, gitlab and also with gitea full path to repo should not matter to client and if needed could be easily changed without affecting url's used by git clients.

@lafriks commented on GitHub (Dec 22, 2017): because just like in github, gitlab and also with gitea full path to repo should not matter to client and if needed could be easily changed without affecting url's used by git clients.

GiteaMirror commented

2025-11-02 03:59:31 -06:00

@MonsieurCellophane commented on GitHub (Dec 22, 2017):

@lafriks Agreed - and as I mentioned, my need is more a historical quirk than anything else. But, there are at least two - possibly three - bugs here:

Absurd error message
Ineffective guard check against the specific use case
The possibility that the 'opt' (or 'usr' or 'etc' or whatever) owner is actually registered with unpredictable effects downstream (probably another irrelevant error message, or - who knows - the cloning of the wrong repo)

Obviously, there is no obligation to fix them by doing what I would see "as the right thing" - but fixing them all is easy enough by replacing SplitN with Split (or using SplitN(blah,3)). And if an absolute path is detected (StartsWith("/") one could even tell the user why what he is doing is wrong (always a good thing).

@MonsieurCellophane commented on GitHub (Dec 22, 2017): @lafriks Agreed - and as I mentioned, my need is more a historical quirk than anything else. But, there are at least two - possibly three - bugs here: 1. Absurd error message 2. Ineffective guard check against the specific use case 3. The possibility that the 'opt' (or 'usr' or 'etc' or whatever) owner is actually registered with unpredictable effects downstream (probably another irrelevant error message, or - who knows - the cloning of the wrong repo) Obviously, there is no obligation to fix them by doing what I would see "as the right thing" - but fixing them all is easy enough by replacing SplitN with Split (or using SplitN(blah,3)). And if an absolute path is detected (StartsWith("/") one could even tell the user *why* what he is doing is wrong (always a good thing).

GiteaMirror commented

2025-11-02 03:59:31 -06:00

@MonsieurCellophane commented on GitHub (Dec 22, 2017):

And in fact, just by a quick code inspection of the code that follows, it would appear that, by tricking gitea into believing it is working with a different user and repo than what is actually specified in the repopath I could cause a git command to be executed on a path of my choosing. So what is at issue here is erroneous validation of user input.

@MonsieurCellophane commented on GitHub (Dec 22, 2017): And in fact, just by a quick code inspection of the code that follows, it would appear that, by tricking gitea into believing it is working with a different user and repo than what is actually specified in the repopath I could cause a git command to be executed on a path of my choosing. So what is at issue here is erroneous validation of user input.

GiteaMirror commented

2025-11-02 03:59:31 -06:00

@stale[bot] commented on GitHub (Feb 9, 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 (Feb 9, 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.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#1396