multiuser Hg access w/o shell account?

[Mark Wielaard]

Hi Tom,

Tom Marble <Tom.Marble at ...> writes:
> The use case I'm trying to work on is Mercurial best practices
> for setting up a multi-user repository.

I just happened to have setup such a beast :) http://icedtea.classpath.org/hg/
[*] Let me know if you want access to the machine so you can look at the setup
yourself.

>  My assumptions are:
> - I only want to support push via ssh (not http) because
>   of more secure authentication and optional compression
> - I want control of exactly what kind of shell privileges
>   each user has
> - Setting up ssh for password-less operation is understood [1]
> - In reviewing the man page for "hg push" [2] it is clear
>   that a shell account is required for ssh pull/push to work.
> - I'm a Mercurial newbie and may have missed the FAQ
>   entry for this on [3]

The mercurial site, documentation, faq and wiki are pretty good. Make sure to
read it all! (Although some of the things about the ssh setup aren't completely
spelled out.)

For icedtea we ended up with the hg-ssh script like Mark suggested. Tom did
first try to setup webdav and http-authentication support, but that didn't
really work out.

> It would seem the most convenient way to handle multiuser
> access then would be to add a local account for each authorized
> remote user who will have commit access where each user is a member of
> the same local UNIX group (for whatever nsswitch.conf authentication
> mechanism is used on the Hg server) and (for Hg only users)
> the shell is set to /bin/rbash [4].  The user(s) who will
> administer Hg on the server must also be in the same UNIX
> group and the .hg files must be set for group write permission.

We created a group icedtea that all ssh-hg users are added to. Users that only
need hg access get a disabled password and login (on debian: adduser --ingroup
icedtea --disabled-password --disabled-login) and get a .ssh/authorized_key file
with the following in it:
command="cd / && hg-ssh
hg/*",no-port-forwarding,no-X11-forwarding,no-agent-forwarding [key id and data]

That way they can only access repositories under /hg (there are only two
testrepo and icedtea) but for specific users you can specify more or less
repositories. They can then start by hg clone
ssh://icedtea.classpath.org/hg/testrepo

> An example of grabbing a mercurial snapshot, adding a file
> and pushing it back to the server is shown below [5].
> 
> I'm assuming that adding many remote committers would be
> fairly straightforward and scriptable.  It seems that rbash
> can sufficiently control shell account usage.  What seems tricky
> is exactly how group write permission must be maintained [6].
> Should the umask be set to 002 in .bash_profile (i.e. fixed
> via ssh)?  Or should one of the Mercurial hooks be used?

umask setting was the hardest to get right. Depending on how users start their
session you can either set it in /etc/login.def or /etc/profile, but the most
reliable way was to do it through pam. And debian aptitude install libpam-umask
And add the following line to the /etc/pam.d/common-session file:

# Explicitly set umask so we have group writable files.
session    optional     pam_umask.so umask=0002


> Are there alternative best practices for multiuser
> commit access via ssh?

The other cool thing to look at is hgwebdir.cgi which can give you both a public
 view of the changelog and make it easily possible to allow anybody to clone and
pull the repositories over http. I can send you the apache config.d/hg.conf and
hgwebdir.config files if you are interested.

Cheers,

Mark

[*] Actually I setup subversion, since I knew how to quickly do that, with a
complete read/write copy of openjdk, but the IcedTea team didn't want that
because they were afraid that would be interpreted as a fork of openjdk, not as
an additional/experimental patchset and they really wanted to use Mercurial so
they were prepared for the OpenJDK future :)