Page MenuHomePhabricator

Make permissions more granular in repositorys
Closed, InvalidPublic


Hi I'm wondering if you can support more granular permissions, e.g. allowing admins to set who can edit a uri in repository without needing permission to edit the whole repo.

Current problem

The root problem is, that you have to give a user the full access to a repo, to edit minor things like projects or uris. So this reduces the amout users that can help with updating settings, due to the fact, that admins may have concerns with security, since a user could change anything and remove lot's of things from the repo (push a commit with most files deleted for example)


The advantage of this is increased user contribution and decreased security concerns since they will only be able to edit what the admin sets them they can edit.

  • This will allow more contributions, because you can give more users access without full access
  • It will allow certain users to maintain a lot of things since sometime admin's are busy and rely on volunteers to help maintain things (for example no admin has time to add projects (tags) to more than 1000 repos (current situation at Wikimedia), so volunteers can add the tags, since we have much more volunteers than admins.

Event Timeline

I don't plan to pursue field-level permissions in any application. They were somewhat recently removed from Maniphest in T10003. That task discusses some of the complications that field-level permissions create in the general case.

I'm not sure I really understand the use case here. For example, editing URIs allows you to replace the contents of a repository with the contents of some other observed repository. The observed repository may be empty, so this is equivalent to pushing a commit which deletes everything. This operation seems dangerous if you consider deleting the repository to be dangerous.

Deleting a repository also isn't necessarily particularly dangerous. If this is the major concern you have, making reverting a repository across a force push easier (T10861) might be a shorter path to a similar goal.

Editing projects can also be dangerous, if object rules or "repository project" rules in Herald are used to protect the repository.

Finally, you can set some controls in Herald which are stronger than Diffusion controls. If you have a global Herald rule which prevents anyone from pushing dangerous changes, users won't be able to force-push a repository even if they disable protection for that repository. If this is your only concern, this permission is already effectively separable. You could conceivably even use Herald to enforce a stronger "Can Push" policy, although this may make the UI somewhat confusing.

Another thing to consider is that your worries may be entirely solved at a social level. Giving people access but reminding them to only modify 'safe' fields. If your users are somewhat trustworthy this is entirely reasonable.

It's also vaguely possible that we'll add "suggest an edit" (ala T4104) in a generic way, then untrusted users could suggest edits and trusted users could approve them. I don't currently plan to build this as a general-purpose workflow, though.

At some point the bulk editor will be generalized to work with all EditEngine applications, including Diffusion. If your edits are primarily "we need to tag a thousand repositories", this would let volunteers do something like this:

  • Find all the repositories that need tag #x.
  • Compile a list of their IDs.
  • Write on a task somewhere "All these repositories need to have tag #x added: link to query results".

Then a user with edit permission could click the link, review the results to make sure they make sense, click Bulk EditAdd Tag and add #x. This isn't perfect, but could reduce the setup cost.

This issue also probably impacts WMF more than other installs (most private installs can afford to give users broader edit permission, since the barrier to entry is higher).

This issue also sounds like it might be largely an onboarding/setup issue, not an ongoing issue? Tags can be edited via the API, so if you have a one-time need to tag a thousand repositories you could conceivably use something like a spreadsheet to coordinate and then have someone just bulk-apply the edits via the API with a few lines of script.

epriestley added a subscriber: paladox.

From the downstream, it seems like the problem may be one specific user wanting to add mirrors to existing repositories:

This power is extremely broad, and equivalent to granting the user "push" + "allow dangerous changes", because they can use an observed URI to replace the contents of the repository with arbitrary new contents in a way that is equivalent to a force push.

Additionally, it looks like this request may really have come from @paladox, and simply been copy-pasted to the upstream verbatim by @Luke081515.2. Here is a paste where @paladox wrote the summary, and @paladox also filed the downstream task:

@paladox has been banned from interacting with this upstream. I'm not certain that this task is @paladox sneakily evading his ban, but it sure looks a lot like that.

WARNING: @Luke081515.2, if you help @paladox evade his ban and interact with the upstream by copy-pasting his requests, you will also be banned from interacting with the upstream.

FWIW: I believe @paladox means well, he's just young/inexperienced and overly enthusiastic. The decision to ban him is entirely reasonable for upstream though, given the circumstances.