AuthenticatingHg » History » Version 15

Version 14 (Chris Cannam, 2010-08-05 06:18 PM) → Version 15/25 (Chris Cannam, 2010-08-11 05:49 PM)

h2. Authentication for Mercurial activity

h3. Requirements

# *Clone/pull from repo for public project*: Any user, no authentication required
# *Clone/pull from repo for private project*: Permitted users only
# *Push to repo for public project*: Permitted users only
# *Push to repo for private project*: Permitted users only
# *Create repo for public project*: User with manager role on project
# *Delete repo or carry out command-line admin tasks*: System admin only

What constitutes a permitted user for limited push or pull activity?

* A user who is a member of the project?
* A user who is identified in the [web] section of the repository?
* A user who is both a member and identified in the [web] section?
* A user who is either a member or identified in the [web] section?
* A user who is identified in the [web] section, if any, or is a member if there is no such section?

h3. Techniques

* Hg repository creation using "reposman.rb":
* Apache authentication against Redmine user database using mod_auth_mysql (no support for LDAP-authenticated users?)
* Apache authentication against Redmine users using "the mod_perl module": ("local copy": or a variant thereof. was designed for SVN access via WebDAV, but the code itself handles access and authentication only?
* Hg repository [web]-section authorisation using "hgwebdir.cgi":

Other links on this subject:

* "Separation between authentication and authorisation activities":
* "hgrc [web] section":
* "Using mod_auth_mysql to authenticate against the Redmine database directly":
* "Apache2 logging from mod_perl code": (for use in debugging

h3. Plan

We are currently using proxypass from a front-end server to the actual code server, so this complicates matters somewhat.

It seems reasonable-ish to assume that all hg traffic will use SSL. Apart from anything else, pushes and any other authenticated traffic really must be over SSL, so this avoids irritations when someone pulls from an http URL and then gets kicked out when attempting to push to the default target.


* Front-end server needs to have the relevant certificates
* Front-end server is currently running too old a version of Apache 2 to support SNI, so it can only support one https domain (question: does Mercurial's own Python client support SNI?) -- fortunately for us it is not currently running any other, but this suggests we really need to replace the front-end arch
* Front-end server redirects all http traffic on the hg domain to https and then proxypasses to the back-end server via http (connection is presumed trusted?)

At the back-end server,

* We will use hgwebdir.cgi instead of serving the hg directories directly as static HTTP
* The server's document root will be just a placeholder
* ScriptAlias is used to point all traffic to hgwebdir.cgi
* We will use something based on to manage access
* We probably want to prevent people reading the list of repositories (so that per-project authentication is always in force)

The net result is that we should have hg over https with basic authentication based on the Redmine database and LDAP as appropriate, with access controls that we can define based on the project rules set out above.

Apache config snippet:
PerlLoadModule Apache::Authn::Redmine

<VirtualHost *:80>
DocumentRoot /var/www/hg

<DirectoryMatch "^/.*/\.svn/">
Order allow,deny
Deny from all
Satisfy All

ScriptAlias / "/var/hg/index.cgi/"

<Location />
AuthName "Mercurial"
AuthType Basic
Require valid-user
PerlAccessHandler Apache::Authn::Redmine::access_handler
PerlAuthenHandler Apache::Authn::Redmine::authen_handler
RedmineDSN "DBI:mysql:database=<database>;host=localhost"
RedmineDbUser "<user>"
RedmineDbPass "<password>"
Options +ExecCGI
AddHandler cgi-script .cgi

ErrorLog /var/log/apache2/error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

ServerSignature Off