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!
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T4104 Implement "suggest profile edit" for recommending profile pictures, phone numbers, etc., to users | ||
| Open | None | T8629 Create some kind of queue of profile/settings action items for users |
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:
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:
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.
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.