Give Gerrit admins ability to impersonate users
Fredrik Luthander
Now that we see a lot more new users on gerrit here at $DAY_JOB 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.
And so, it dawned on us the other day that, as admins, we have access
to this information already, by the database, only it's not very
accessible in that format.
It would actually be a lot better if we as admins could impersonate
the user, and more specifically, impersonate them while in the
settings section.
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.
Please let me know if you have any thoughts on this. Again, I'll be
happy to enter any tickets resulting from a discussion like this that
would lead to features in this direction.
BR,
Fredrik
Michael Poole
> Please let me know if you have any thoughts on this. Again, I'll be
> happy to enter any tickets resulting from a discussion like this that
> would lead to features in this direction.
As a local administrator, I've wished for two things along these lines:
1) Set users' full names. (Many of them forget to do that. I could
track them down and bother them about it, but fixing it for them seems
quicker and more reliable -- at least at the current scale.)
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.)
Michael Poole
Nasser Grainawi
2 is covered by issue 503 [1].
Can you use LDAP for 1? That's a nice way to handle it.
[1] http://code.google.com/p/gerrit/issues/detail?id=503
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Shawn Pearce
> Michael Poole wrote:
>>
>> Fredrik Luthander writes:
>>
>>> Please let me know if you have any thoughts on this. Again, I'll be
>>> happy to enter any tickets resulting from a discussion like this that
>>> would lead to features in this direction.
>>
>> As a local administrator, I've wished for two things along these lines:
>>
>> 1) Set users' full names. (Many of them forget to do that. I could
>> track them down and bother them about it, but fixing it for them seems
>> quicker and more reliable -- at least at the current scale.)
>>
>> 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.)
>
> Can you use LDAP for 1? That's a nice way to handle it.
>
> [1] http://code.google.com/p/gerrit/issues/detail?id=503
Exactly what Nasser said.
However, LDAP may not work for everyone. There are some folks using
OpenID. Or using HTTP and don't have an LDAP directory available to
rely on. So I still think the need to edit a user's full name is a
reasonable request.
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 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?
out. It would however help to be able to both clear it and set another
password. Very optional though.
> 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.
persuade someone over at $DAY_JOB sign up for it.
BR,
Fredrik
Shawn Pearce
<fredrik....@sonyericsson.com> wrote:
> 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.
True.
> 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?
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.