113 locked out. Multiple admins can use Mercurial's version control to cooperate on |
113 locked out. Multiple admins can use Mercurial's version control to cooperate on |
114 controlling access to the repository server in a natural way. You can also add |
114 controlling access to the repository server in a natural way. You can also add |
115 "root" users by putting their key in the "keys/root" directory in just the same |
115 "root" users by putting their key in the "keys/root" directory in just the same |
116 way - these users will now be able to control hgadmin and create new |
116 way - these users will now be able to control hgadmin and create new |
117 repositories just as you can. |
117 repositories just as you can. |
|
118 |
|
119 Once you're working with "hgadmin", it can be convenient to remove all the keys |
|
120 in "/etc/mercurial-server/keys" and all the entries in |
|
121 "/etc/mercurial-server/access.conf" and use hgadmin to control everything. If |
|
122 you find yourself locked out, you can get back in again by restoring some of the |
|
123 entries you removed from these files - remember, |
|
124 "/etc/mercurial-server/access.conf" takes precedence over the "access.conf" in |
|
125 "hgadmin". |
118 |
126 |
119 ACCESS.CONF |
127 ACCESS.CONF |
120 |
128 |
121 Out of the box, there are just two kinds of users: the ones with keys in |
129 Out of the box, there are just two kinds of users: the ones with keys in |
122 "keys/root" and those in "keys/users". However, you can change this by editing |
130 "keys/root" and those in "keys/users". However, you can change this by editing |
223 |
231 |
224 Finally, hook in an extension is run for each changeset that is remotely |
232 Finally, hook in an extension is run for each changeset that is remotely |
225 committed, which uses the rules file to determine whether to allow the |
233 committed, which uses the rules file to determine whether to allow the |
226 changeset. |
234 changeset. |
227 |
235 |
228 LOCKED OUT? |
236 SECURITY OF MERCURIAL-SERVER |
229 |
237 |
230 Once you're working with "hgadmin", it can be convenient to remove all the keys |
238 mercurial-server relies entirely on sshd to grant access to remote users. As a |
231 in "/etc/mercurial-server/keys" and all the entries in |
239 result, it runs no daemons, installs no setuid programs, and no part of it runs |
232 "/etc/mercurial-server/access.conf" and use hgadmin to control everything. If |
240 as root except the install process: all programs run as the user hg. And any |
233 you find yourself locked out, you can get back in again by restoring some of the |
241 attack on mercurial-server can only be started if the Bad Guys already have a |
234 entries you removed from these files - remember, |
242 public key in ~hg/.ssh/authorized_keys, otherwise sshd will bar the way. No |
235 "/etc/mercurial-server/access.conf" takes precedence over the "access.conf" in |
243 matter what command the user tries to run on the remote system via ssh, |
236 "hgadmin". |
244 mercurial-server is run. |
|
245 |
|
246 It parses the command line the user asked for, and interprets and runs the |
|
247 corresponding hg operation itself if access is allowed, so users can only read |
|
248 and add to history within repositories; they cannot run any other hg command. In |
|
249 addition, every push and pull is logged with a datestamp, changeset ID and the |
|
250 key that performed the operation. |
|
251 |
|
252 However, while the first paragraph holds no matter what bugs mercurial-server |
|
253 contains, the second depends on the relevant code being correct; though the |
|
254 entire codebase is currently only about twice as long as this README, |
|
255 mercurial-server is a fairly new program and may harbour bugs. Backups are |
|
256 essential! |
237 |
257 |
238 THANKS |
258 THANKS |
239 |
259 |
240 Thanks for reading this far. If you use mercurial-server, please tell me about |
260 Thanks for reading this far. If you use mercurial-server, please tell me about |
241 it. |
261 it. |