# HG changeset patch # User Paul Crowley # Date 1255603994 -3600 # Node ID 45dac87ae794233124bc73433b011b7fbfd281c2 # Parent aa57f48c758580c009a8cb967ffa5bcc8057e893 Repository names are directories diff -r aa57f48c7585 -r 45dac87ae794 doc/manual.docbook --- a/doc/manual.docbook Thu Oct 15 11:50:06 2009 +0100 +++ b/doc/manual.docbook Thu Oct 15 11:53:14 2009 +0100 @@ -99,7 +99,8 @@ At this stage, no-one but you has any access to any repositories you create on this system. In order to give anyone else access, you'll need a copy of their SSH public key; we'll assume you have that key in -~/sam-key.pub. To manage access, you make changes to the special hgadmin repository. +~/sam-key.pub. To manage access, you make changes to the special hgadmin repository. jay@my-workstation:~$ hg clone ssh://hg@repository-host/hgadmin destination directory: hgadmin @@ -124,7 +125,8 @@ Sam can now read and write to your ssh://hg@repository-host/repository/name repository. Most other changes to access control can be made simply by making and -pushing changes to hgadmin, and you can use Mercurial to +pushing changes to hgadmin, and you can use Mercurial to cooperate with other root users in the normal way. @@ -133,7 +135,8 @@ putting the key in the right place under /etc/mercurial-server/keys, and re-running sudo -u hg /usr/share/mercurial-server/refresh-auth. -However, using hgadmin is usually more convenient if you need to make more than a very few changes; it also makes it easier to share administration with others and provides a log of all changes. +However, using hgadmin is usually more convenient if you need to make more than a very few changes; it also makes it easier to share administration with others and provides a log of all changes. @@ -143,20 +146,26 @@ Out of the box, mercurial-server supports two kinds of users: "root" users and normal users. If you followed the steps above, you are a "root" user because your key is under keys/root, while the other user you gave access to is a normal user since their key is under keys/users. Keys that are not in either of these directories will by default have no access to anything. -Root users can edit hgadmin, create new repositories and read and write to existing ones. Normal users cannot access hgadmin or create new repositories, but they can read and write to any other repository. +Root users can edit hgadmin, create new repositories and read and write to existing ones. Normal users cannot access hgadmin or create new repositories, but they can read and write to any other repository.
Using access.conf -mercurial-server offers much more fine-grained access control than this division into two classes of users. Let's suppose you wish to give Pat access to the widget repository, but no other. We first copy Pat's SSH public key into the keys/pat directory in hgadmin. This tells mercurial-server about Pat's key, but gives Pat no access to anything because the key is not under either widget repository, but no other. We first copy Pat's SSH public key into the keys/pat directory in hgadmin. This tells mercurial-server about Pat's key, but gives Pat no access to anything because the key is not under either keys/root or keys/users. To grant this key access, we must give mercurial-server a new access rule, so we create a file in hgadmin called access.conf, with the following contents: +class='directory'>keys/users. To grant this key access, we must give mercurial-server a new access rule, so we create a file in hgadmin called access.conf, with the following contents: # Give Pat access to the "widget" repository write repo=widget user=pat -Pat will have read and write access to the widget repository as soon as we add, commit, and push these files. +Pat will have read and write access to the widget repository as soon as we add, commit, and push these files. Each line of access.conf has the following syntax: @@ -204,7 +213,8 @@ When considering a request, mercurial-server steps through all the rules in /etc/mercurial-server/access.conf and then all the -rules in access.conf in hgadmin +rules in access.conf in hgadmin looking for a rule which matches on every condition. The first match determines whether the request will be allowed; if there is no match in either file, the request will be denied. @@ -219,7 +229,8 @@ These rules ensure that root users can do any operation on any repository, -that no other users can access the hgadmin repository, +that no other users can access the hgadmin repository, and that those with keys in keys/users can read or write to any repository but not create repositories. Some examples of how these rules work: @@ -272,7 +283,8 @@ /etc/mercurial-server and hgadmin mercurial-server consults two distinct locations to collect information about what to allow: /etc/mercurial-server and its own hgadmin repository. This is useful for several reasons: +class='directory'>/etc/mercurial-server and its own hgadmin repository. This is useful for several reasons: @@ -285,7 +297,8 @@ xlink:href="http://reductivelabs.com/products/puppet">Puppet -If a change to hgadmin leaves you "locked out", hgadmin leaves you "locked out", /etc/mercurial-server allows you a way back in. @@ -293,16 +306,21 @@ -Rules in /etc/mercurial-server/access.conf are checked before those in hgadmin, and keys in /etc/mercurial-server/keys will be present no matter how hgadmin changes. +Rules in /etc/mercurial-server/access.conf are checked before those in hgadmin, and keys in /etc/mercurial-server/keys will be present no matter how hgadmin changes. We anticipate that once mercurial-server is successfully installed and -working you will usually want to use hgadmin for most +working you will usually want to use hgadmin for most access control tasks. Once you have the right keys and -access.conf set up in hgadmin, you +access.conf set up in hgadmin, you can delete /etc/mercurial-server/access.conf and all of /etc/mercurial-server/keys, -turning control entirely over to hgadmin. +turning control entirely over to hgadmin. /etc/mercurial-server/remote-hgrc is in the @@ -438,9 +456,11 @@ refresh-auth recurses through the /etc/mercurial-server/keys and the keys directory in the -hgadmin repository, creating an entry in +hgadmin repository, creating an entry in ~hg/.ssh/authorized_keys for each one. This is redone -automatically whenever a change is pushed to hgadmin. +automatically whenever a change is pushed to hgadmin.