SoundSoftware Code Site

Authentication for Mercurial activity¶

Requirements¶

1. Clone/pull from repo for public project: Any user, no authentication required
2. Clone/pull from repo for private project: Permitted users only
3. Push to repo for public project: Permitted users only
4. Push to repo for private project: Permitted users only
5. Create repo for public project: User with manager role on project
6. 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?

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 Redmine.pm (local copy) or a variant thereof. Redmine.pm 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 Redmine.pm)

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.

Therefore,

• 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 our own SoundSoftware.pm based on Redmine.pm 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.

Because of our front-end server limitations, we will use only a single domain name. That is, hg will be served through https://code.soundsoftware.ac.uk/hg/ rather than https://hg.soundsoftware.ac.uk/ as we might otherwise do. We can do this straightforwardly, because a ScriptAlias for /hg in the Apache config will take effect before mod_passenger gets to the request (no rewrite needed).

Thus Apache config:

PerlLoadModule Apache::Authn::SoundSoftware

<VirtualHost *:80>
        ServerName code.soundsoftware.ac.uk
        ServerAdmin <me>

        DocumentRoot /var/www/redmine/public
        PassengerRestartDir restart_files
        PassengerHighPerformance on
        PassengerMaxRequests 5000
        PassengerStatThrottleRate 10
        RailsSpawnMethod smart
        ExpiresDefault "access plus 1 minute" 

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

        <Directory /var/www/redmine/public>
                Options -MultiViews
        </Directory>

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

        <Location /hg>
                AuthName "Mercurial" 
                AuthType Basic
                Require valid-user
                PerlAccessHandler Apache::Authn::SoundSoftware::access_handler
                PerlAuthenHandler Apache::Authn::SoundSoftware::authen_handler
                SoundSoftwareDSN "DBI:mysql:database=<db>;host=localhost" 
                SoundSoftwareDbUser "<user>" 
                SoundSoftwareDbPass "<password>" 
                SoundSoftwareRepoPrefix "/var/hg/" 
                Options +ExecCGI
                AddHandler cgi-script .cgi
                ExpiresDefault now
        </Location>

        ErrorLog /var/log/apache2/error.log
        LogLevel warn

        ServerSignature Off
</VirtualHost>

Problem: hgwebdir.cgi refuses to accept authentication if it is not running under SSL (it just spits out "ssl required"). That's reasonable enough, except that the user connection is under SSL, it's just the connection within the virtual host wrapper that is not. It can be fixed in hgweb.config, see below. We also want to set the config to permit anyone to push, because we are using the mod_perl authentication module rather than the repository configuration to determine who is permitted.

[web]
push_ssl = false
allow_push = *

Now... what about creating repositories?