LDAP - setting user as admin (via objectclass) makes them admin forever - saves the setting into database. #561

New Issue

GiteaMirror · 2025-11-02T03:28:11-06:00

GiteaMirror commented

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

Originally created by @kubatyszko on GitHub (Mar 21, 2017).

Gitea version (or commit ref): master
Git version:
Operating system: Linux
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

I'm using LDAP authentication with correct user and admin objectClass filters.
When user logs in for the first time, if they match the admin filter - they are set as admin in the database forever.

I would expect it to be always dynamically controlled via LDAP - not using the value stored in DB.

I don't expect to be able to control this using admin interface -> users (that should probably have the "administrator" column greyed out.

I DO see that upon each login the value is being checked with ldap - but not used...

Originally created by @kubatyszko on GitHub (Mar 21, 2017). - Gitea version (or commit ref): master - Git version: - Operating system: Linux - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - [ ] Not relevant - Log gist: ## Description I'm using LDAP authentication with correct user and admin objectClass filters. When user logs in for the first time, if they match the admin filter - they are set as admin in the database forever. I would expect it to be always dynamically controlled via LDAP - not using the value stored in DB. I don't expect to be able to control this using admin interface -> users (that should probably have the "administrator" column greyed out. I DO see that upon each login the value is being checked with ldap - but not used...

GiteaMirror added the type/feature issue/confirmed labels 2025-11-02 03:28:11 -06:00

GiteaMirror closed this issue

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

GiteaMirror commented

2025-11-02 03:28:12 -06:00

@strk commented on GitHub (Mar 22, 2017):

Same issue filed on Gogs: https://github.com/gogits/gogs/issues/2855

@strk commented on GitHub (Mar 22, 2017): Same issue filed on Gogs: https://github.com/gogits/gogs/issues/2855

GiteaMirror commented

2025-11-02 03:28:12 -06:00

@strk commented on GitHub (Mar 22, 2017):

Gogs PR attempting to fix it: https://github.com/gogits/gogs/pull/3062
The PR is a generic SYNC method dealing with the generic LDAP sync issue reported in Gogs on https://github.com/gogits/gogs/issues/1268

Maybe someone wants to complete that PR and port to Gitea ?
\cc @ptman

@strk commented on GitHub (Mar 22, 2017): Gogs PR attempting to fix it: https://github.com/gogits/gogs/pull/3062 The PR is a generic SYNC method dealing with the generic LDAP sync issue reported in Gogs on https://github.com/gogits/gogs/issues/1268 Maybe someone wants to complete that PR and port to Gitea ? \cc @ptman

GiteaMirror commented

2025-11-02 03:28:13 -06:00

@strk commented on GitHub (Mar 22, 2017):

@lunny milestone should probably not be 1.x.x (1.2.0 or later, I'd think)

@strk commented on GitHub (Mar 22, 2017): @lunny milestone should probably not be 1.x.x (1.2.0 or later, I'd think)

GiteaMirror commented

2025-11-02 03:28:13 -06:00

@DblK commented on GitHub (May 5, 2017):

Also mentioned in the PR #1478

@DblK commented on GitHub (May 5, 2017): Also mentioned in the PR #1478

GiteaMirror commented

2025-11-02 03:28:13 -06:00

@ptman commented on GitHub (May 5, 2017):

Btw, is it possible to determine admin-privilege using group membership instead of objectclass? There might not be a suitable objectclass and active directory and freeipa don't really recommend extending the schema

@ptman commented on GitHub (May 5, 2017): Btw, is it possible to determine admin-privilege using group membership instead of objectclass? There might not be a suitable objectclass and active directory and freeipa don't really recommend extending the schema

GiteaMirror commented

2025-11-02 03:28:14 -06:00

@stale[bot] commented on GitHub (Feb 14, 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 14, 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#561