Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker login reports sucessful login with incorrect password / token #20563

Closed
noerw opened this issue Jul 31, 2022 · 4 comments · Fixed by #22119
Closed

docker login reports sucessful login with incorrect password / token #20563

noerw opened this issue Jul 31, 2022 · 4 comments · Fixed by #22119

Comments

@noerw
Copy link
Member

noerw commented Jul 31, 2022

Description

$ docker login localhost:3000
Username: foobar
Password: 
Login Succeeded

↑ this should fail as i entered gibberish for the password

$ docker push localhost:3000/foobar/qgis
Using default tag: latest
The push refers to repository [localhost:3000/foobar/qgis]
5a1bd4bee150: Layer already exists 
1b04ddff91f2: Layer already exists 
4dd0c5812fd4: Layer already exists 
unauthorized: authentication required

↑ ACLs seem to generally work at least ;)

Gitea Version

692707f

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

build from source

Database

SQLite

@algernon
Copy link
Contributor

FWIWI, this appears to be the relevant code:

func Authenticate(ctx *context.Context) {
u := ctx.Doer
if u == nil {
u = user_model.NewGhostUser()
}
token, err := packages_service.CreateAuthorizationToken(u)
if err != nil {
apiError(ctx, http.StatusInternalServerError, err)
return
}
ctx.JSON(http.StatusOK, map[string]string{
"token": token,
})
}

I would assume Doer is nil here, because of:

r.Use(func(ctx *context.Context) {
ctx.Doer = authGroup.Verify(ctx.Req, ctx.Resp, ctx, ctx.Session)
})

Thus, since Doer is nil, it the first block of code uses the ghost user, and thus, succeeds. If my assumption is correct, then it should treat Doer being nil as an error and 403.

Mind you, this is just my quick impression of the code, I have not verified either of the above assumptions.

@algernon
Copy link
Contributor

FWIW, I have a fix prepared for this, PR will be coming up shortly.

@algernon
Copy link
Contributor

...I spoke too soon. The ghost user is required for anonymous pulls, which also hit the token URL, so just going off of ctx.Doer being nil alone is incorrect. I'll have a PR up shortly anyway. :)

@lunny lunny added this to the 1.17.2 milestone Aug 18, 2022
@lunny lunny modified the milestones: 1.17.2, 1.17.3 Sep 5, 2022
@6543 6543 modified the milestones: 1.17.3, 1.17.4 Oct 13, 2022
@lunny
Copy link
Member

lunny commented Dec 13, 2022

The Auth interface need to be refactored to have a new return argument which indicate should we continue the next auth method.

@lunny lunny modified the milestones: 1.17.4, 1.17.5 Dec 21, 2022
lunny added a commit that referenced this issue Dec 28, 2022
This PR changed the Auth interface signature from 
`Verify(http *http.Request, w http.ResponseWriter, store DataStore, sess
SessionStore) *user_model.User`
to 
`Verify(http *http.Request, w http.ResponseWriter, store DataStore, sess
SessionStore) (*user_model.User, error)`.

There is a new return argument `error` which means the verification
condition matched but verify process failed, we should stop the auth
process.

Before this PR, when return a `nil` user, we don't know the reason why
it returned `nil`. If the match condition is not satisfied or it
verified failure? For these two different results, we should have
different handler. If the match condition is not satisfied, we should
try next auth method and if there is no more auth method, it's an
anonymous user. If the condition matched but verify failed, the auth
process should be stop and return immediately.

This will fix #20563

Co-authored-by: KN4CK3R <[email protected]>
Co-authored-by: Jason Song <[email protected]>
lunny added a commit to lunny/gitea that referenced this issue Dec 28, 2022
…#22119)

This PR changed the Auth interface signature from 
`Verify(http *http.Request, w http.ResponseWriter, store DataStore, sess
SessionStore) *user_model.User`
to 
`Verify(http *http.Request, w http.ResponseWriter, store DataStore, sess
SessionStore) (*user_model.User, error)`.

There is a new return argument `error` which means the verification
condition matched but verify process failed, we should stop the auth
process.

Before this PR, when return a `nil` user, we don't know the reason why
it returned `nil`. If the match condition is not satisfied or it
verified failure? For these two different results, we should have
different handler. If the match condition is not satisfied, we should
try next auth method and if there is no more auth method, it's an
anonymous user. If the condition matched but verify failed, the auth
process should be stop and return immediately.

This will fix go-gitea#20563

Co-authored-by: KN4CK3R <[email protected]>
Co-authored-by: Jason Song <[email protected]>
lunny added a commit that referenced this issue Dec 29, 2022
…22259)

backport #22119

This PR changed the Auth interface signature from `Verify(http
*http.Request, w http.ResponseWriter, store DataStore, sess
SessionStore) *user_model.User`
to 
`Verify(http *http.Request, w http.ResponseWriter, store DataStore, sess
SessionStore) (*user_model.User, error)`.

There is a new return argument `error` which means the verification
condition matched but verify process failed, we should stop the auth
process.

Before this PR, when return a `nil` user, we don't know the reason why
it returned `nil`. If the match condition is not satisfied or it
verified failure? For these two different results, we should have
different handler. If the match condition is not satisfied, we should
try next auth method and if there is no more auth method, it's an
anonymous user. If the condition matched but verify failed, the auth
process should be stop and return immediately.

This will fix #20563

Co-authored-by: KN4CK3R <[email protected]>
Co-authored-by: Jason Song <[email protected]>
@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants