Merge lp:~mr-russ/bzr/add-doc-for-shared-ssh-server into lp:bzr

[Russell Smith]

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/14/2011 11:51 AM, Russell Smith wrote:
> Russell Smith has proposed merging lp:~mr-russ/bzr/add-doc-for-shared-ssh-server into lp:bzr.
>
> Requested reviews:
> bzr-core (bzr-core)
>
> For more details, see:
> https://code.launchpad.net/~mr-russ/bzr/add-doc-for-shared-ssh-server/+merge/53217

The prose seems a bit rough in areas, but not enough that I would block it.

My primary concern is the recommendation to filter into
"/srv/bzr/{alice,bob}" subdirs. The issue is that if /srv/bzr is a
shared repository, than I'm pretty sure neither Alice nor Bob can
actually push new content. Since it will try to grab the shared repo,
but find it is outside of the chroot. Either that, or it will not be
able to see it, and always create a new repo underneath alice/ and bob/.

Have you tried this explicitly to see if it works the way you describe it?

John
=:->

 review: needsinfo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk19+CUACgkQJdeBCYSNAAPbDgCeJ7c8/8cuOwckZuiEQ/Gi+y4E
CDYAnj6GX1qN2mkKJCrbFlcxCBowdQ/c
=q1Up
-----END PGP SIGNATURE-----

review: Needs Information

[Russell Smith (mr-russ)]

The structure is not designed to handle a shared repository at the /srv/bzr level. It's for a directory tree that may contain multiple shared repositories, one for alice and and one for bob.

But to be sure, I have now tested it and it doesn't work if you don't allow access to a full repository/shared-repository.

My original use-case is to have a bzr area, much like apache's SVN repo list. Discussions with vila on the bzr channel indicate that you can use any path names prior to the actual repository. We could have a shared repository at /srv/bzr/a/b/c/shared-repository. Restrictions could be applied to users at a,b or c as these are normal directories.

I have assumed the language is not helpful in the documentation and attempted to update it to be clearer about what you are allowed to restrict. I've pushed an updated patch for further review and comment.

[Andrew Bennetts (spiv)]

This looks basically good, thank you! I have some comments though:

In terms of markup, you should probably use ReST's “::” marker for preformatted blocks, like the example authorized_keys lines (although we should verify that it won't cause excessively wide pages; if it does there's probably some magic sphinx/ReST markup we can use to workaround that though…).

For me the most important part of this section about how to use a single user account on the server to host branches for multiple users, so it should be titled and introduced accordingly. A fair few users ask about how to set that up and it would be nice to make it easy to find. (The earlier sections have already described the case where the users already have their own accounts and home directories.) A title like “Using a restricted SSH account for multiple users and/or simpler paths” might be clearer, although it's certainly more verbose! (Thinking about this makes me think that the existing “Further Configuration” section probably needs retitling and/or rearranging too, but that's obviously out-of-scope for your patch.)

I think your example authorized_keys lines are missing the --inet option, which means they won't work. I'd in fact suggest using the contrib/bzr_ssh_path_limiter script as the command= in authorized_keys, because it will give a nicer error to users that attempt to use that SSH key for something other than bzr, and would avoid this particular problem.

If you don't have time to address these points soon let us know, I'd be happy to tackle them and get this landed in time for 2.4.

review: Needs Fixing

[Russell Smith (mr-russ)]

I've push a new version that has the required cleanup of the formatting. I've not adjusted the wording too much for the main content as I think it's still hitting the mark.

after IRC discussion the contrib/bzr_ssh_path_limiter was not used as it's not installed by default and increases the difficulty level for getting this setup up and running.

review: Needs Resubmitting

[Andrew Bennetts (spiv)]

This now looks good enough to merge, I think. We can always make more improvements later!

review: Approve

[Andrew Bennetts (spiv)]

Sent to pqm by email. I decided to fix a typo and small grammar issue first, so I submitted lp:~spiv/bzr/add-doc-for-shared-ssh-server which adds those tweaks to this branch.

Thanks very much for improving our documentation!

=== modified file 'doc/en/admin-guide/simple-setups.txt'
--- doc/en/admin-guide/simple-setups.txt	2010-09-06 20:47:57 +0000
+++ doc/en/admin-guide/simple-setups.txt	2011-03-23 07:48:07 +0000
@@ -91,3 +91,52 @@
 
 .. [#] The version of Bazaar installed on the server must be at least 2.1.0b1 
        or newer to support ``/~/`` in bzr+ssh URLs.
+
+Using a restricted SSH account to host multiple users and repositories
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Once you have a bzr+ssh setup using a shared repository.  You may want to share
+that repository among a small set of developers.  Using shared SSH access enables
+you to complete this task without any complicationed setup or ongoing management.
+
+To allow multiple users to access bazaar over ssh we can allow ssh access to a common
+account that only allows users to run a specific command.  Using a single account
+simplifies deployment as no permissions management issues exist for the filesystem.
+All users are the same user at the server level.  Bazaar labels the commits with
+each users details so seperate server accounts are not required.
+
+To enable this configuration we update the ``~/.ssh/authorized_keys`` to include 
+command restrictions for connecting users.
+
+In these examples the user will be called ``bzruser``.
+
+The following example shows how a single line is configured::
+
+  command="bzr --serve --inet --allow-writes --directory=/srv/bzr",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...= my bzr key
+
+This command allows the user to access only bzr and disables other SSH use.  Write
+access to each repository in the directory ``/srv/bzr`` has been granted with ``--allow-writes``
+and can be removed for individual users that should only require read access.  The root of
+the directory structure can be altered for each user to allow them to see only a subet
+of the repositories available.  The example below assumes two seperate repositories
+for Alice and Bob.  This method will not allow you to restrict access to part
+of a repository, you may only restrict access to a single part of the directory structure::
+
+  command="bzr --serve --inet --allow-writes --directory=/srv/bzr/alice/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...= Alice's SSH Key
+  command="bzr --serve --inet --allow-writes --directory=/srv/bzr/bob/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...= Bob's SSH Key
+  command="bzr --serve --inet --allow-writes --directory=/srv/bzr/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...= Repo Manager SSH Key
+
+Alice and Bob have access to their own repository and Repo Manager
+has access to the each of their repositories.  Users are not allowed access to any part of 
+the system except the directory specified. The bzr+ssh urls are simplified by 
+serving using ``bzr serve`` and the ``--directory`` option.
+
+If Alice logs in she uses the following command for her fix-1023 branch::
+
+  $ bzr log bzr+ssh://[e-mail]/fix-1023
+
+If Repo Manager logs in he uses the following command to access Alice's
+fix-1023::
+
+  $ bzr log bzr+ssh://[e-mail]/alice/fix-1023
+