| Issue 702: | Gui for Gerrit admins to change other users settings | |
| 24 people starred this issue and may be notified of changes. | Back to list |
From this discussion thread: http://groups.google.com/group/repo-discuss/browse_thread/thread/aa18da15887dc612# Fredrik Luthander: [...]it's apparent how much support you need to get started when you have very little previous knowledge of the system. So the admins of the system end up spending a lot of time sending instructions to the user, making them check their settings in the gerrit settings page. <snip> How large a challenge would it be to implement a way for the admins to impersonate/view and make changes to the settings page of another user? This would allow for a lot of seamless troubleshooting not involving the user as much, and we would be more efficient in our support. Michael Poole: <snip> 2) Retire accounts for people who are no longer with the company. (By "retire" I primarily mean they should not show up in the suggested completions for text boxes, but there might be other places that should also be modified.) Shawn Pearce: <snip> I'm not OK with the idea of impersonating a user. I am however OK with the idea that an Administrator can view and modify most of a user's settings panel. Especially something relatively harmless like their full name, or changing the preferred email address. Where it gets touchy is, can the Administrator add an SSH key for the user? Can the Administrator see the user's password? I think those two operations should be forbidden. But it is reasonable for the admin to see/change the username. Or to see the current SSH keys, or even to delete them. That way they can lock out an SSH key as soon as they know its compromised or otherwise must be invalidated. I've always planned to have a Admin > Users tab, to manage contributor agreements, and simple per-user settings. But I just never got time to develop it. If someone does the work, I think it would make a lot of admins happy. Fredrik Luthander: I see your point and I both agree and disagree with you. :) I see the sensitivity of the matter and the potential power it would give, but I also think that the time saved by allowing me as an admin to insert an additional key for the user (we've seen problem with users having problems with the cut'n'paste operation... :-/ ) would make up for it. A way to disarm the sensitivity of this would be if we could add a transparancy to what we're doing. An example of that would be if gerrit sent a status email everytime an admin changed any sensitive data for the user. Example: "ALERT: Admin Fredrik deleted public RSA key ####1" "ALERT: Admin Fredrik added public RSA key ###2" The mailing mechanism is already in place. Why not use it? And the fact is that the key is already stored in the DB, physically accessible by the machine admin. So it's a question of how easy it should be to do this? Maybe it's own right so not all admins can do it, in case you have many admins? > Can the Administrator see the user's password? I did not have reading the password in mind, so we would darken that out. It would however help to be able to both clear it and set another password. Very optional though. <snip> Shawn Pearce: <snip quote from Fredrik> > The mailing mechanism is already in place. Why not use it? I like this idea. If we are going to permit an admin to modify this data, we should try to notify the user. > And the fact is that the key is already stored in the DB, physically > accessible by the machine admin. So it's a question of how easy it > should be to do this? Maybe it's own right so not all admins can do > it, in case you have many admins? My issue is, my Administrators group is larger than those who have login access to the database. Its hard to a Venn diagram by email. But I guess I can explain the trust like this: - UNIX root - Gerrit database admin / direct write access to filesystem - Administrators group - Project owners - Everyone else As it so happens, our Administrators group is like 2-4x the number of those with database admin or UNIX root rights. Those admins can create projects, or should be able to fix a user's full name or username field. But they probably shouldn't be able to add an SSH key on behalf of the user. So I probably would prefer it if we could restrict who can add an SSH key to another user's account. ------------------------------------------------------------------------ Conclusion: Admins need one view which lists all the users, and another view which is the settings page of a user selected for edit. All fields that the user can change should be changable including adding RSA public keys. If the user has a password it should be hidden (password form field), but possible to overwrite. If an admin performs any tasks concerning the keys, an email notifying the user of the action should be sent. These two views should be protected by a separate permission, so that not everyone in the admin group can perform these tasks by default. Shawn, can you elaborate on how permissions for this should be granted, if it's not the administrators group that should be able to do this or grant this permission by default?
May 20, 2011
Project Member
#1
nas...@grainawi.org
Status:
Accepted
Dec 5, 2013
New user who is frustrated by finally getting the ssh kay created and in the right places to begin editing OpenStack document tickets, but can't because git-review asks for a password (that I did not create) and can't get beyond with any password I have used in the last six months. As long as there is transparency (email notice to user when performed) I would welcome this change. I'm not sure who to contact to try and resolve this as I don't know what is triggering it.. |
|
| ► Sign in to add a comment |