Gitea: Authorization error for shared LFS objects

[Gravemind]

• 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, 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.

[lafriks]

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

[Gravemind]

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)

[lafriks]

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]

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.

[Gravemind]

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)

[lafriks]

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]

@Gravemind have submitted PR to fix for newly added files

[lafriks]

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

[Gravemind]

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 ?

[lafriks]

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

[Gravemind]

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

[lafriks]

Ok, than I think I'm closing this issue