Blog dot Melimato dot Com

One of the things that stumbled me the most about bazaar is that it does not have a own authentication method. Users can access repositories through ssh, sftp, etc. While this is very usefull if everyone working on the repo has shell access to the server, it does not allow “virtual users” the way svn does. Well, not out of the box anyway… There’s always a workaround. This post tries to explain how to configure Bazaar in the centralized model and set user level permissions to the working directory.

Setup initial repository on server

Init central repository with no working trees, since no-one is going to be committing in the central server. I’m calling it bzr_test.

user@server$ cd /path/to/repo/base
user@server$ bzr init-repo --no-trees bzr_test

Init first branch (trunk) on newly created repo:

user@server$ bzr init bzr_test/trunk

Securing with bzr_access on server

(http://bazaar-vcs.org/BzrAccess)

Firstly, get the bzr sources from launchpad, unpack it and copy the bzr_access script located in the contrib directory to some path, I usually use /usr/local/sbin.

user@server$ cd /tmp
user@server$ wget http://launchpad.net/bzr/2.0/2.0.1/+download/bzr-2.0.1.tar.gz
user@server$ tar zxfv bzr-2.0.1.tar.gz
user@server$ cd bzr-2.0.1
user@server$ cp contrib/bzr_access /path/to/bzr_access

or

user@server$ wget http://bazaar-vcs.org/bzr/bzr.dev.knits/contrib/bzr_access -O /path/to/bzr_access

And make sure the script is executable:

user@server$ chmod +x /path/to/bzr_access

Then, add a system user to be used to access the repository:

user@server$ sudo adduser \
    --system \
    --shell /bin/sh \
    --gecos 'bzr version control' \
    --group \
    --disabled-password \
    --home /path/to/repo \
    bzr_username

Once you created the system user, create a .ssh dir in the user’s home directory (I use the repository’s root)

user@server$ mkdir ~bzr_username/.ssh
user@server$ vi ~bzr_username/.ssh/authorized_keys

And add the following line (one per user) to the user’s authorized_keys file:

# ~bzr_username/.ssh/authorized_keys
command="/path/to/bzr_access /path/to/bzr /path/to/repo username",no-port-forwarding,no-X11-forwarding,no-agent-forwarding CLIENT_PUBLIC_KEY

Parameters:
/path/to/bzr_access = /usr/local/sbin/bzr_access
/path/to/bzr: Can be found by executing whereis bzr. Usually in /usr/bin/bzr
/path/to/repo: /home/development/bzr/bzr_test bzr
username: bzr_username
CLIENT_PUBLIC_KEY: is the client’s public key found in ~/.ssh/id_rsa.pub on the client’s machine

Now, you need to add a bzr_access.conf file to your repo’s root:

user@server$ vi /path/to/repo/bzr_access.conf

# /path/to/repo/bzr_access.conf
[groups]
admins = admin1
devels = user1, user2, user3
 
[/]
@admins = rw
@devels = r

OK! Your repo is initted and secured! User admin1 is an admin and cat read & write to the repo while user1, user2 and user3 are devels and have only read access.

Checkout or branch the repository on the client

user@client$ mkdir bzr_test
user@client$ cd bzr_test
user@client$ bzr co bzr+ssh://bzr_username@melimato.com/trunk my_checkedout_trunk
user@client$ bzr branch bzr+ssh://bzr_username@melimato.com/trunk my_branch

Limitations

Taken from http://bazaar-vcs.org/BzrAccess

Currently, each bzr_access.conf configuration file is limited to specifying the access control for the directory that it is in. As such, to cater for a setup with multiple projects that should be segregated, one must either

Create a user account for each project, thus duplicating the configuration for each user account but allowing each user to maintain just one SSH key pair.

Create a single user account, but require each user to have an SSH key pair for each project. They will then have to select the appropriate private key to access the desired directory. Each of these directories will have its own bzr_access.conf, but there need be only one authorized_keys file.

Create an SSH key pair for each project and have users share private keys. However, removing the access of a user from a given directory will mean revoking a key pair and issuing a new private key to the other users with access to that directory.