193 </listitem> |
193 </listitem> |
194 </itemizedlist> |
194 </itemizedlist> |
195 <para> |
195 <para> |
196 "*" only matches one directory level, where "**" matches as many as you |
196 "*" only matches one directory level, where "**" matches as many as you |
197 want. More precisely, "*" matches zero or more characters not including "/" |
197 want. More precisely, "*" matches zero or more characters not including "/" |
198 while "**" matches zero or more characters including "/". |
198 while "**" matches zero or more characters including "/". So |
199 </para> |
199 <code>projects/*</code> matches <filename |
200 <para> |
200 class='directory'>projects/foo</filename> but not <filename |
201 When considering a request, mercurial-server steps through all the rules in <filename>/etc/mercurial-server/access.conf</filename> and then all the rules in <filename>access.conf</filename> in <literal>hgadmin</literal> looking for a rule which matches on every condition. If it does not find such a rule, it denies the request; otherwise it checks whether the rule grants sufficient privilege to allow it. |
201 class='directory'>projects/foo/bar</filename>, while |
202 </para> |
202 <code>projects/**</code> matches both. |
203 <para> |
203 </para> |
204 By default, <filename>/etc/mercurial-server/access.conf</filename> has the following rules: |
204 <para> |
|
205 When considering a request, mercurial-server steps through all the rules in |
|
206 <filename>/etc/mercurial-server/access.conf</filename> and then all the |
|
207 rules in <filename>access.conf</filename> in <literal>hgadmin</literal> |
|
208 looking for a rule which matches on every condition. The first match |
|
209 determines whether the request will be allowed; if there is no match in |
|
210 either file, the request will be denied. |
|
211 </para> |
|
212 <para> |
|
213 By default, <filename>/etc/mercurial-server/access.conf</filename> has the |
|
214 following rules: |
205 </para> |
215 </para> |
206 <programlisting>init user=root/** |
216 <programlisting>init user=root/** |
207 deny repo=hgadmin |
217 deny repo=hgadmin |
208 write user=users/** |
218 write user=users/** |
209 </programlisting> |
219 </programlisting> |
210 <para> |
220 <para> |
211 These rules ensure that root users can do any operation on any repository, that no other users can access the <literal>hgadmin</literal> repository, and that those with keys in <filename class='directory'>keys/users</filename> can read or write to any repository but not create repositories. |
221 These rules ensure that root users can do any operation on any repository, |
212 </para> |
222 that no other users can access the <literal>hgadmin</literal> repository, |
|
223 and that those with keys in <filename |
|
224 class='directory'>keys/users</filename> can read or write to any repository |
|
225 but not create repositories. If these are the only rules in effect, they |
|
226 have the following consequences: |
|
227 </para> |
|
228 <itemizedlist> |
|
229 <listitem> |
|
230 Any request from a user with a key under <filename |
|
231 class='directory'>keys/root</filename> will match the first rule; since |
|
232 this rule is <literal>init</literal> the request will always be allowed. |
|
233 </listitem> |
|
234 <listitem> |
|
235 Any request to access the <literal>hgadmin</literal> by any other user will |
|
236 not match the first rule, but will match the second rule, and so will be |
|
237 denied. |
|
238 </listitem> |
|
239 <listitem> |
|
240 Any request to create a repository from a user with a key in <filename |
|
241 class='directory'>keys/users</filename> will not match the first or second |
|
242 rules, but will match the third rule. This is a <literal>write</literal> |
|
243 rule, which doesn't grant the privilege to create repositories, so the |
|
244 request will be denied. |
|
245 </listitem> |
|
246 <listitem> |
|
247 Any request to access an existing repository from a user with a key in |
|
248 <filename class='directory'>keys/users</filename> will not match the first |
|
249 or second rules, but will match the third rule, which grants |
|
250 <literal>write</literal> privilege, so the request will be allowed. |
|
251 </listitem> |
|
252 <listitem> |
|
253 Any request from any user whose key is in neither <filename |
|
254 class='directory'>keys/root</filename> nor <filename |
|
255 class='directory'>keys/users</filename> will not match any rule and so will |
|
256 be denied. Unless it matches the second rule, in which case it will still |
|
257 be denied. Changes to the <filename>access.conf</filename> in <literal>hgadmin</literal> will change that, as the example at the start of this section shows. |
|
258 </listitem> |
|
259 <listitem> |
|
260 Any request from a user whose key not under the <filename |
|
261 class='directory'>keys</filename> directory at all will always be denied, |
|
262 no matter what rules are in effect; because of the way SSH authentication |
|
263 works, they will be prompted to enter a password, but no password will |
|
264 work. This can't be changed. |
|
265 </listitem> |
|
266 </itemizedlist> |
213 </section> |
267 </section> |
214 <section> |
268 <section> |
215 <title>/etc/mercurial-server and hgadmin</title> |
269 <title>/etc/mercurial-server and hgadmin</title> |
216 <para> |
270 <para> |
217 mercurial-server consults two distinct locations to collect information about what to allow: <filename |
271 mercurial-server consults two distinct locations to collect information about what to allow: <filename |