Specific member of group not able to access project that has given access to group

Gitlab FOSS 12.3.1

I have a specific user that is part of the "permission/gash_rw" group, as Developer. I have various projects under the "qa/pyshl/*" namespace.

The group "permission/gash_rw" is a member of a "qa/pyshl/pre-commit-pyshl" project, with Developer permissions, similarly, for the project "qa/pyshl/model".

The "permission/gash_rw" has about 700 members and I verified randomly that members of that group are able to access both the "qa/pyshl/pre-commit-pyshl" and "qa/pyshl/model" project, except for (so far I could find) a single user.

When impersonating a random other user of the 'gash_rw' group, the "qa/pyshl/pre-commit-pyshl" project shows up as expected.

This specific account is active, not blocked. There are no error logs whatsoever in sidekiq/unicorn.

When I retrieve the user list for the project through the API the user IS listed.

eg, https://host/api/v4/projects/135/members/all?per_page=100&page=10

{"id":1497,"name":"Varshini XXX"username":"varshinm","state":"active","avatar_url":"https://secure.gravatar.com/avatar/xxxx","web_url":"https://example/varshinm","access_level":30,"expires_at":null},

api/v4/users/1497/projects gives an empty list. (request was authenticated as admin)

Thank you.

changed the description

mentioned in issue #32875 (closed)

@jansmets Is the user able to access the qa/pyshl/pre-commit-pyshl project directly (e.g. if you visit the qa/pyshl/model project and replace manually model with pre-commit-pyshl in the address bar)?

added devopsmanage groupauthentication and authorization [DEPRECATED] needs investigation permissions typebug labels

No, not directly either. (and doing the API call as that user results in {"message":"404 Project Not Found"} ) Thanks.

Ok, could you please try to refresh the project authorizations for that user:

1. Open a Rails console and run the following:

$ user = User.find_by_username!('<username>')
$ project = Project.find_by_full_path('qa/pyshl/pre-commit-pyshl')
$ project.team.developers.where(id: user.id).to_a
$ user.refresh_authorized_projects
$ project.team.developers.where(id: user.id).to_a

Please redact anything that you don't want to share before posting. Thanks!

irb(main):004:0> user = User.find_by_username!('varshinm')
=> #<User id:1497 @varshinm>
irb(main):005:0> project = Project.find_by_full_path('qa/pyshl/pre-commit-pyshl')
=> #<Project id:135 qa/pyshl/pre-commit-pyshl>
irb(main):006:0> project.team.developers.where(id: user.id).to_a
=> []
irb(main):007:0> user.refresh_authorized_projects
=> #<User id:1497 @varshinm>
irb(main):008:0> project.team.developers.where(id: user.id).to_a
=> [#<User id:1497 @varshinm>]

This indeed makes the project accessible.

Cool, thanks for updating me.

@jeremy Do you recall similar issues with permissions that aren't up-to-date?

Is there anything more I can do to ensure this isn't happening for other projects/groups ? Can I force a global refresh?

And I also have problems with newly Deploy keys not working for docker registry access. So something seems pretty wrong with my instance.

changed the description

mentioned in issue #32972 (closed)

mentioned in issue #33305

mentioned in issue #33499 (closed)

mentioned in issue #33957 (closed)

mentioned in issue #34464 (closed)

mentioned in issue #35028 (closed)

mentioned in issue #35480 (closed)

mentioned in issue #35975 (closed)

mentioned in issue #36566 (closed)

Setting ~"Category:Authentication and Authorization" based on ~"group::access".

Setting ~"Category:Authentication and Authorization" based on ~"group::access".

Setting ~"Category:Authentication and Authorization" based on ~"group::access".

added 1 deleted label

added sectiondev label

added vintage label

Hi @jansmets ,

Thanks for raising this bug.

Contributions like this are vital to help make GitLab a better product.

We would be grateful for your help in verifying whether your bug report requires further attention from the team. If you think this bug still exists, and is reproducible with the latest stable version of GitLab, please comment on this issue.

This issue has been inactive for more than 12 months now and based on the policy for inactive bugs, will be closed in 7 days.

Thanks for your contributions to make GitLab better!

added stale label

Hi @jansmets ,

Thanks for raising this bug.

Contributions like this are vital to help make GitLab a better product.

We would be grateful for your help in verifying whether your bug report requires further attention from the team. If you think this bug still exists, and is reproducible with the latest stable version of GitLab, please comment on this issue.

This issue has been inactive for more than 12 months now and based on the policy for inactive bugs, will be closed in 7 days.

Thanks for your contributions to make GitLab better!

Hi @jansmets ,

Thanks for raising this bug.

Contributions like this are vital to help make GitLab a better product.

We would be grateful for your help in verifying whether your bug report requires further attention from the team. If you think this bug still exists, and is reproducible with the latest stable version of GitLab, please comment on this issue.

This issue has been inactive for more than 12 months now and based on the policy for inactive bugs, will be closed in 7 days.

Thanks for your contributions to make GitLab better!

Hi @jansmets ,

Based on the policy for inactive bugs, this issue is now being closed.

If you think this bug still exists, and is reproducible with the latest stable version of GitLab, please reopen this issue.

Thanks for your contributions to make GitLab better!

closed

added auto closed label