Page MenuHomePhabricator

Implement "suggest profile edit" for recommending profile pictures, phone numbers, etc., to users
Open, LowPublic


I get the following error: "You do not have permission to edit this object. Users with the 'Can Edit' capability: / By default, no one can take this action. / Only you can edit your information."

How can I give myself the "Can Edit" capability, or whatever else is needed? I'm an administrator; I should have all capabilities!

Event Timeline

jonah214 raised the priority of this task from to Needs Triage.
jonah214 updated the task description. (Show Details)
jonah214 added a subscriber: jonah214.

I'm an administrator; I should have all capabilities!

Phabricator's security model gives administrators as few powers as possible. Particularly, administrators usually can not:

  • violate policies;
  • bypass audit trails;
  • impersonate users; or
  • destroy data.

This reduces the cost of administrative account compromise (the attacker can't really do anything with an admin account) and means it's OK to make someone an admin so they can do administrative work even if they can't see all the data in Phabricator. "Admin" is more like "janitor" than "all-powerful lord of the install".

We might eventually introduce a mode where admins are all-powerful, but will probably do this only behind an overwhelming tide of user feedback and confusion, which hasn't materialized yet.

For the actual issue:

  • for system agents, you can edit it in the People application.
  • for other users, there's no way to do it right now. One thing we've thought about in the past is letting you suggest an edit, which the profile owner could accept or reject. An alternative is that we could build CLI tools for this, but there was at least some interest in editing other profile details and custom fields, and doing that from the CLI would be a bit of a mess.

Fair enough, but this doesn't seem like something Administrators ought not be able to do. It violates policies, but that doesn't address the underlying reason for the policy (which I am not aware of), it does not violate audit trails, it doesn't impersonate users in a really meaningful way (about the worst thing I could do is change someone's picture to a cat, and is that really even a bad thing?), and it doesn't destroy data.

This just seems like a field that administrators should be able to edit for everyone.

The reasoning for the policy is just that you should own your own profile. Although the profile image doesn't have any additional implications, other fields (like email addresses or mobile numbers) do have security implications, now or in the future.

For example, if we just say "administrators can edit anyone's profile", an attacker who gains access to an administrator account could potentially bypass two-factor auth by editing a user's profile and changing their mobile number in the future (there's no two-factor auth support today, but this is the sort of consideration shaping the policy choice). At the same time, this is a field administrators might reasonably want to edit (for example, by automatically adding a company-issued phone number). A solution like "suggest profile edit" probably handles this scenario better than blanket administrative edit.

The policy is also more consistent with other policies, where administrators never have special override access which punches through anything. Generally, keeping policies as simple as possible seems highly desirable.

We could special case this field without breaking anything, but if we keep doing that in the long term we'll end up with a more complex and potentially more dangerous policy model.

epriestley renamed this task from How can I edit someone else's profile picture? to Implement "suggest profile edit" for recommending profile pictures, phone numbers, etc., to users.Nov 18 2013, 4:36 PM
epriestley triaged this task as Low priority.
epriestley added a project: Profile.

Seriously folks, why make this design decision? I have a user with a long history in my Phabricator install that now cannot get into his account and cannot remember what email address he used to create the account. Under a normal system scenario where I'm Admin, I can just go into his account, tell him which address he used, chastise him for forgetting and not keeping notes and that's it.

With your design scheme I'm forced to create another account for him and erase his history, or dig around in the database to see what his actual user record shows.

Your security design scheme is idealistic, but nowhere near idiot-proof. I mean, all you guys are accomplishing is making more work for admins by tying our hands and removing our ability from helping users quickly.