140 class='directory'>/etc/mercurial-server/keys</filename>, and re-running |
140 class='directory'>/etc/mercurial-server/keys</filename>, and re-running |
141 <userinput>sudo -u hg /usr/share/mercurial-server/refresh-auth</userinput>. |
141 <userinput>sudo -u hg /usr/share/mercurial-server/refresh-auth</userinput>. |
142 However, using <literal>hgadmin</literal> 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. |
142 However, using <literal>hgadmin</literal> 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 </para> |
143 </para> |
144 </section> |
144 </section> |
145 <section> |
145 </section> |
146 <title>Basic access control</title> |
146 <section> |
|
147 <title>Access control</title> |
147 <para> |
148 <para> |
148 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 <filename class='directory'>keys/root</filename>, while the other user you gave access to is a normal user since their key is under <filename class='directory'>keys/users</filename>. Keys that are not in either of these directories will by default have no access to anything. |
149 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 <filename class='directory'>keys/root</filename>, while the other user you gave access to is a normal user since their key is under <filename class='directory'>keys/users</filename>. Keys that are not in either of these directories will by default have no access to anything. |
149 </para> |
150 </para> |
150 <para> |
151 <para> |
151 Root users can edit <literal>hgadmin</literal>, create new repositories and read and write to existing ones. Normal users cannot access <literal>hgadmin</literal> or create new repositories, but they can read and write to any other repository. This is only the default configuration; for more advanced configuration read <xref linkend="accesscontrol"/>. |
152 Root users can edit <literal>hgadmin</literal>, create new repositories and read and write to existing ones. Normal users cannot access <literal>hgadmin</literal> or create new repositories, but they can read and write to any other repository. |
152 </para> |
153 </para> |
153 </section> |
154 <section> |
154 </section> |
155 <title>Using access.conf</title> |
155 <section id="accesscontrol"> |
|
156 <title>Access control</title> |
|
157 <para> |
156 <para> |
158 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 <literal>widget</literal> repository, but no other. We first copy Pat's SSH public key into the <filename |
157 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 <literal>widget</literal> repository, but no other. We first copy Pat's SSH public key into the <filename |
159 class='directory'>keys/widget/pat</filename> directory in <literal>hgadmin</literal>. Now mercurial-server knows about Pat's key, but will give Pat no access to anything because the key is not under either <filename |
158 class='directory'>keys/widget/pat</filename> directory in <literal>hgadmin</literal>. Now mercurial-server knows about Pat's key, but will give Pat no access to anything because the key is not under either <filename |
160 class='directory'>keys/root</filename> or <filename |
159 class='directory'>keys/root</filename> or <filename |
161 class='directory'>keys/users</filename>. To grant this key access, we must give mercurial-server a new access rule, so we create a file in <literal>hgadmin</literal> called <filename>access.conf</filename>, with the following contents:</para> |
160 class='directory'>keys/users</filename>. To grant this key access, we must give mercurial-server a new access rule, so we create a file in <literal>hgadmin</literal> called <filename>access.conf</filename>, with the following contents:</para> |
217 <para> |
216 <para> |
218 "*" only matches one directory level, where "**" matches as many as you |
217 "*" only matches one directory level, where "**" matches as many as you |
219 want. More precisely, "*" matches zero or more characters not including "/" |
218 want. More precisely, "*" matches zero or more characters not including "/" |
220 while "**" matches zero or more characters including "/". |
219 while "**" matches zero or more characters including "/". |
221 </para> |
220 </para> |
|
221 </section> |
222 <section> |
222 <section> |
223 <title>/etc/mercurial-server and hgadmin</title> |
223 <title>/etc/mercurial-server and hgadmin</title> |
224 <para> |
224 <para> |
225 mercurial-server consults two distinct locations to collect information about what to allow: <filename |
225 mercurial-server consults two distinct locations to collect information about what to allow: <filename |
226 class='directory'>/etc/mercurial-server</filename> and its own <literal>hgadmin</literal> repository. This is useful for several reasons: |
226 class='directory'>/etc/mercurial-server</filename> and its own <literal>hgadmin</literal> repository. This is useful for several reasons: |