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

Ensure there is always one user with admin privileges #15449

Closed
2 of 6 tasks
thopico opened this issue Apr 13, 2021 · 6 comments · Fixed by #19423
Closed
2 of 6 tasks

Ensure there is always one user with admin privileges #15449

thopico opened this issue Apr 13, 2021 · 6 comments · Fixed by #19423
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@thopico
Copy link

thopico commented Apr 13, 2021

  • Gitea version (or commit ref): docker image gitea/gitea:1.14.0-rootless
  • Git version: 2.30.2
  • Operating system: Debian buster
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No (need admin privileges)
  • Log gist:

Description

Hi, today doing a dumb test with my prod instance, I remove myself from the admin group (where I was alone).
This was not a big deal as I could get it back through cli, but it seems to me it would be better if Gitea prevents this kind of mistake.

Either it could check if at least one admin remains after removal, or it could disallow removing admin privileges to the logged in user?

Thanks in advance.

@lunny lunny added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Apr 13, 2021
@wxiaoguang
Copy link
Contributor

wxiaoguang commented Apr 16, 2022

You can add admin users back by ./gitea admin ...

@thopico
Copy link
Author

thopico commented Apr 16, 2022

Hello @wxiaoguang
You didn't answer my question.
Nevertheless, you can decide not to address this issue, and close it. But your answer makes me doubt you have read my issue entirely (what a pity when one does make the effort to clearly define the issue).

I know ./gitea admin ..., it helped me recover admin privileges. I am just thinking about the instances whose admin has no access to the server (and therefore is not able to execute ./gitea admin ...).
But it is more like a feature, so I interpret your answer as "I don't have time for this".

Which is fine :)

Bye

@wxiaoguang wxiaoguang reopened this Apr 16, 2022
@wxiaoguang
Copy link
Contributor

I have read the issue. Indeed there could be a lot of "dumb" operations, for example, you set an OTP and forgot the recovery code, or you changed the password but forgot it, and even someone changes the record from database.

Since there is a way to recover the mistake, it seems not worth to check everything again and again.

ps: I closed many inactive issues recently, this issue has been a long time and seems not getting interest to get a PR. If you can propose a PR, I can help to review and approve.

@thopico
Copy link
Author

thopico commented Apr 16, 2022

I understand your point and agree not to make too many checks neither address every possible situation.
However, I believe (correct me if I'm wrong) admin users are relatively autonomous within the instance. For example, they have the possibility to change any user's password from the web UI (but I didn't check for the OTP case).
This is what pushed me to raise this issue : maintain this autonomy as much as possible and prohibit behavior that can dip into it (especially for behaviors that will never make sense [i.e. no admin on the instance])

I don't have time neither appropriate skills to propose a PR, and nobody else seems concerned by this issue. So it is fine to close the issue.

Thank you for your detailed answer.

@lunny
Copy link
Member

lunny commented Apr 17, 2022

Hi, today doing a dumb test with my prod instance, I remove myself from the admin group (where I was alone).
Could I assume that you did that in admin panel -> users?

@thopico
Copy link
Author

thopico commented Apr 18, 2022

Yes exactly.

@lunny lunny added this to the 1.16.6 milestone Apr 19, 2022
@6543 6543 modified the milestones: 1.16.6, 1.16.7 Apr 20, 2022
@6543 6543 modified the milestones: 1.16.7, 1.16.8 May 1, 2022
@wxiaoguang wxiaoguang removed this from the 1.16.8 milestone May 5, 2022
zeripath pushed a commit that referenced this issue May 8, 2022
Admin should not be able to delete themselves.

Also partially fix #15449
AbdulrhmnGhanem pushed a commit to kitspace/gitea that referenced this issue Aug 24, 2022
Admin should not be able to delete themselves.

Also partially fix go-gitea#15449
@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.
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants