My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
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
Status:  Accepted
Owner:  ----


Sign in to add a comment
 
Project Member Reported by fredrik....@sonyericsson.com, Sep 1, 2010
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
(No comment was entered for this change.)
Status: Accepted
Dec 5, 2013
#2 bill.lam...@gmail.com
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

Powered by Google Project Hosting