In my environment, it’s important to limit access to the vcs repository. We need to limit general access to the code, commit access on different branches, as well as the ability to create branches in certain areas. In this post I’m going to look at how to handle permissions to lock down/allow different operations. Here is the repository structure I’m working with:
[andrew karma] /Users/andrew/Development/BZR
>>>>>> tree repo
repo
`– myProject.trunk
1 directory, 0 files
Just my trunk branch in the repository. All of these files (the .bzr, the directories etc.) are owned by me. I should be able to do anything I want in the repository. Like creating a new branch. So, I have my trunk branch, and my first release branch in the repository.
[andrew karma] /Users/andrew/Development/BZR
>>>>>> bzr branch repo/myProject.trunk repo/myProject.R1
Branched 0 revision(s).[andrew karma] /Users/andrew/Development/BZR
>>>>>> tree repo
repo
|– myProject.R1
`– myProject.trunk
2 directories, 0 files
Testing with various permissions
Below is a table of various permission settings and the directory/files I applied the permissions to. I chowned all of the files to root:wheel and messed with the global permissions. In actual production you’d want to use some combination of group permissions/setuid bits/umasks to make sure everything works. So, when I list the permissions below, I’m only referring to the permissions I had on the specified directory/set of files. x was only ever set on directories.
| Location | rwx | Action | Worked? | Notes |
|---|---|---|---|---|
| repo/myProject.trunk | — | commit | No | As expected |
| repo/myProject.trunk | r– | commit | No | Just being able to read the top level branch dir isn’t enough. Remember, I still have full perms on the .bzr directory. |
| repo/myProject.trunk | r-x | commit | Yes | Needed x on the top level dir. This isn’t surprising since all of the action takes place in the .bzr directory. |
| repo/myProject.trunk | — | checkout | No | As expected |
| repo/myProject.trunk | r– | checkout | No | Same as commit |
| repo/myProject.trunk | r-x | checkout | Yes | Same as commit. We need x on the branch directory |
| If we have r_x on the branch dir that contains the .bzr dir, we can checkout/modify the branch. Below, I’m going to look at what happens when we mess with perms on .bzr. The tests above did not show how to setup a read only branch. I’m anticipating that mucking with the .bzr permissions will let me do that. |
||||
| repo/myProject.trunk/.bzr | — | commit | No | As expected. No perms on the .bzr directory means I can’t write. |
| repo/myProject.trunk/.bzr | r– | commit | No | Read perms on the .bzr dir won’t let me commit |
| repo/myProject.trunk/.bzr | r-x | commit | Yes | r-x on the .bzr directory lets me commit. |
| At this point I suspect the checkout tests will be the same so I’m not going to run them. Next step is to change perms on all files within the .bzr directory. I wasn’t anticipating the simple top level directory perms to get me anywhere, I just wanted to see what the effects were. Note, the x perms are only applied to directories in the perms list below. |
||||
| repo/myProject.trunk/.bzr/* | r-x | checkout | Yes | With full read access (and x on dirs) I can checkout the branch |
| repo/myProject.trunk/.bzr/* | r-x | commit | No | With just r-[x] I can checkout, but I can’t commit. Good |
| repo/myProject.trunk/.bzr/* | rwx | commit | Yes | As expected, with rw[x] I can commit to the branch. |
| Now we know something about perms and how they relate to checkouts and committing. I’m going to assume that branching, updates, and merging follow the same rules. Now, lets take a quick look at creating branches within the repo. This is not going to be anything shocking given the above, but it’s worth putting down for completeness. | ||||
| repo/myProject.trunk | r-x | branch | No | trying to create a branch within myProject.trunk failed, no write perms on the directory |
| repo/myProject.trunk | rwx | branch | Yes | using the branch command I was able to create myProject.feature1 within trunk. |
Conclusion
So, permissions in bzr work about as I expected. The only time you really care about permissions on any directory other than the .bzr directory (and its contents) is when you want to create a branch. Creating a branch requires rwx on the branch target. To create a read only branch you need to give your users r-x permissions on all of the files in the .bzr directory. To allow them to write, they’ll need rwx. The next trick is to figure out how to manage these permissions. There is a tool called sheila for CVS that handled doling out permissions as needed. I’ll need something similar for bzr. Another way to approach this issue is to look at the hooks provided in the bzr server. I’d like to not have to mess with groups/file permissions if I don’t have to. Having restrictions enforced by the software controlling the commits gives me a bit more flexibility. Perhaps for my next post I’ll dig into that a bit. As always, let me know if you liked this, or if you have any other comments.
