Splitting up Git administer permissions

Matt Cooper

January 27th, 20170 0

Like everything in VSTS and TFS, Git repos are protected by a set of permissions. For instance, you must have Read for a repo to clone or view its contents. Likewise, you must have Contribute to push changes. Until recently, you needed one permission to create, delete, or rename a repo, edit branch policies, or change other people’s permissions: Administer.

We heard from several customers that Administer covered too many scenarios. For instance, at one customer, anyone can create new repos and rename any repo they created. Due to compliance regulations, no one can delete a repo they created (only a select group of people have that capability). At another customer, for company policy reasons, separate individuals control branch policies (the repo owner), adding & removing other people’s permissions (project administrators), and deleting repos (like the previous customer, restricted to only a handful of people).

With Administer covering all of these capabilities in one permission, both customers were unable to delegate some authority without delegating all authority. In practice, this meant that only a small set of people were responsible for all repo creation and management, creating a bottleneck for engineers every time they wanted a new repo.

You’ve probably guessed what I’m going to say next: we’ve split the Administer permission into 6 new permissions. Those new permissions are:

Create repository
Delete repository
Rename repository
Edit policies
Manage permissions
Remove others’ locks

We automatically migrate permissions on upgrade (meaning that if you previously had Administer on a a repo or at the project level, you now have these 6 new permissions on that repo or project). When you create a new repo, we automatically grant Delete, Rename, Edit policies, Manage permissions and Remove others’ locks on that repo, equivalent to the old behavior of granting Administer.

We also took this opportunity to clean up the names of a few existing permissions. Several of them were awkwardly phrased. “Force push” is a well-understood Git concept, so we promoted it to the front of its corresponding permission name. Mapping from old name to new, the renamed permissions are:

Branch creation → Create branch
Note management → Manage notes
Rewrite and destroy history (force push) → Force push (rewrite history and delete branches)
Tag management → Manage tags

These changes apply to VSTS effective with the current sprint’s release (rolling out now) and will come to TFS 2017 in Update 1. You’ll know the change has landed in your account when you go to Version Control permissions and see the new permissions:

Small caveat: Until Update 1 releases, users who set permissions using the command-line tf.exe git permissions tool will not be able to grant or revoke the new permissions against a VSTS account. The workaround in the short term is to set permissions with TFSSecurity.exe or the admin tab in the web experience.

It’s now pretty easy to let anyone create a new repo in your project without giving them full administrative control. Grant the Contributors group “Create repository” and you’re all set.

Edit: Removed a reference to “M112”. It means “the sprint we recently finished and are starting to deploy now”, so that’s what I said instead 🙂 Also, added a picture showing what the new permissions will look like in your account.