Authorization error for shared LFS objects #1191

New Issue

GiteaMirror · 2025-11-02T03:51:57-06:00

GiteaMirror commented

2025-11-02 03:51:57 -06:00

Originally created by @Gravemind on GitHub (Oct 27, 2017).

Gitea version: 1.2.2
Git version: 2.14.2
Operating system: Linux
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite

Description

Some git lfs object cannot be fetched, but only for some objects for some users:

Authentication required: Authorization error: http://localhost:3000/use/b/info/lfs/objects/...."

From looking at the lfs objects that worked and those who don't, I am now pretty sure it happens when the same lfs object is used by multiple private repositories, ie: when the same file is copied and added in lfs from multiple repositories.

I tracked the authentication up to this auth check in modules/lfs/server.go, but I am not yet fluent enough in go to continue.

It seems reproducible by doing something like this:

create 2 gitea user
create 2 repo from the 1st user
git track, add, commit, and push the same file in both repo
add the second user as colaborator to only the 2nd repo
the second user gets 401 on the lfs object from the second repo

If needed I can write a more detailed repro procedure.

EDIT: repro: the second user needs to NOT be collaborator of the first repo.

Originally created by @Gravemind on GitHub (Oct 27, 2017). - Gitea version: 1.2.2 - Git version: 2.14.2 - Operating system: Linux - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite ## Description Some git lfs object cannot be fetched, but only for some objects for some users: ``` Authentication required: Authorization error: http://localhost:3000/use/b/info/lfs/objects/...." ``` From looking at the lfs objects that worked and those who don't, I am now pretty sure it happens when the **same lfs object is used by multiple private repositories**, ie: when the same file is copied and added in lfs from multiple repositories. I tracked the authentication up to [this auth check in modules/lfs/server.go](https://github.com/go-gitea/gitea/blob/d81cf34e37657ca0dba28ff45389ee341d90deb0/modules/lfs/server.go#L121), but I am not yet fluent enough in go to continue. It seems reproducible by doing something like this: - create 2 gitea user - create 2 repo from the 1st user - git track, add, commit, and push the same file in both repo - add the second user as colaborator to only the 2nd repo - the second user gets 401 on the lfs object from the second repo If needed I can write a more detailed repro procedure. EDIT: repro: the second user needs to NOT be collaborator of the first repo.

GiteaMirror added the type/bug label 2025-11-02 03:51:57 -06:00

GiteaMirror closed this issue

2025-11-02 03:51:57 -06:00

GiteaMirror commented

2025-11-02 03:51:58 -06:00

@lafriks commented on GitHub (Oct 27, 2017):

I was able to reproduce problem with your provided steps but from what it looks like from gitea LFS code it won't be easy fix as I first thought as in gitea database reference between only first lfs object and repo is saved but not for second repository. So to me it looks like it needs to create data fix migration step to fully fix this

@lafriks commented on GitHub (Oct 27, 2017): I was able to reproduce problem with your provided steps but from what it looks like from gitea LFS code it won't be easy fix as I first thought as in gitea database reference between only first lfs object and repo is saved but not for second repository. So to me it looks like it needs to create data fix migration step to fully fix this

GiteaMirror commented

2025-11-02 03:51:58 -06:00

@Gravemind commented on GitHub (Oct 27, 2017):

In my case, I will try to change the "can read repo" auth check by a simple "is registered user" check for now (anyone registered has the "security level" to access all LFS files anyway).

And maybe the big lfs oid hash already secures it ? Maybe "has to know the hash to get the file anyway" could be considered as secure ? Put another way, could a malicious someone could know the hash of the file, but not the content ? could the hash/oid could leak without an access the git repo in the first place ? (I am not a security guy, so I will not make that assumption for now)

@Gravemind commented on GitHub (Oct 27, 2017): In my case, I will try to change the "can read repo" auth check by a simple "is registered user" check for now (anyone registered has the "security level" to access all LFS files anyway). And maybe the big lfs oid hash already secures it ? Maybe "has to know the hash to get the file anyway" could be considered as secure ? Put another way, could a malicious someone could know the hash of the file, but not the content ? could the hash/oid could leak without an access the git repo in the first place ? (I am not a security guy, so I will not make that assumption for now)

GiteaMirror commented

2025-11-02 03:51:58 -06:00

@lafriks commented on GitHub (Oct 27, 2017):

most probably that will be most fastest way to get it working.
I'm trying to fix now so that new oid/repo combinations are saved correctly

@lafriks commented on GitHub (Oct 27, 2017): most probably that will be most fastest way to get it working. I'm trying to fix now so that new oid/repo combinations are saved correctly

GiteaMirror commented

2025-11-02 03:51:58 -06:00

@lafriks commented on GitHub (Oct 27, 2017):

NB! Do not delete repositories containing LFS objects as it is possible that LFS file from server can get deleted even if other repository still references it.

@lafriks commented on GitHub (Oct 27, 2017): NB! Do not delete repositories containing LFS objects as it is possible that LFS file from server can get deleted even if other repository still references it.

GiteaMirror commented

2025-11-02 03:51:58 -06:00

@Gravemind commented on GitHub (Oct 27, 2017):

Great thanks !

One last uneducated idea, the JWT token can be trusted right ? then maybe, when there is a JWT, a fast code path could be to resolve the repo from the JWT instead of from the LFS meta data...

(EDIT: sorry about the close missclick, time to go to bed here, thanks again)

@Gravemind commented on GitHub (Oct 27, 2017): Great thanks ! One last uneducated idea, the JWT token can be trusted right ? then maybe, when there is a JWT, a fast code path could be to resolve the repo from the JWT instead of from the LFS meta data... (EDIT: sorry about the close missclick, time to go to bed here, thanks again)

GiteaMirror commented

2025-11-02 03:51:58 -06:00

@lafriks commented on GitHub (Oct 27, 2017):

No need for that.. Easiest way for you would be to currently change to not check repository from object ID but just using:

	repositoryString := rv.User + "/" + rv.Repo
	repository, err := models.GetRepositoryByRef(repositoryString)

	if err != nil {
		log.Debug("Could not find repository: %s - %s", repositoryString, err)
		writeStatus(ctx, 404)
		return
	}

@lafriks commented on GitHub (Oct 27, 2017): No need for that.. Easiest way for you would be to currently change to not check repository from object ID but just using: ``` repositoryString := rv.User + "/" + rv.Repo repository, err := models.GetRepositoryByRef(repositoryString) if err != nil { log.Debug("Could not find repository: %s - %s", repositoryString, err) writeStatus(ctx, 404) return } ```

GiteaMirror commented

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

@lafriks commented on GitHub (Oct 29, 2017):

@Gravemind have submitted PR to fix for newly added files

@lafriks commented on GitHub (Oct 29, 2017): @Gravemind have submitted PR to fix for newly added files

GiteaMirror commented

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

@lafriks commented on GitHub (Jan 16, 2018):

Problem have been solved for newly added files in 1.3.x but I fixing repositories with already existing file that is in multiple repositories LFS is quite problematic and it could take a lot of time to create migration for that

@lafriks commented on GitHub (Jan 16, 2018): Problem have been solved for newly added files in 1.3.x but I fixing repositories with already existing file that is in multiple repositories LFS is quite problematic and it could take a lot of time to create migration for that

GiteaMirror commented

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

@Gravemind commented on GitHub (Jan 16, 2018):

Thanks @lafriks , is there anyway to maybe manually force a re-upload of the "shared" LFS files for each repos to re-register them properly in the db ?

@Gravemind commented on GitHub (Jan 16, 2018): Thanks @lafriks , is there anyway to maybe manually force a re-upload of the "shared" LFS files for each repos to re-register them properly in the db ?

GiteaMirror commented

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

@lafriks commented on GitHub (Jan 16, 2018):

you can try running git lfs push --all but I don't know if it will help. Let me know if this helps you.

@lafriks commented on GitHub (Jan 16, 2018): you can try running `git lfs push --all` but I don't know if it will help. Let me know if this helps you.

GiteaMirror commented

2025-11-02 03:52:00 -06:00

@Gravemind commented on GitHub (Jan 17, 2018):

Yes, git lfs push --all origin seems to have fixed the auth, Thanks.

@Gravemind commented on GitHub (Jan 17, 2018): Yes, `git lfs push --all origin` seems to have fixed the auth, Thanks.

GiteaMirror commented

2025-11-02 03:52:00 -06:00

@lafriks commented on GitHub (Jan 17, 2018):

Ok, than I think I'm closing this issue

@lafriks commented on GitHub (Jan 17, 2018): Ok, than I think I'm closing this issue

GiteaMirror referenced this issue

2025-11-02 11:54:57 -06:00