From db70595b877c669dacf52f0fbf59a6f4c29e08c1 Mon Sep 17 00:00:00 2001 From: Sitaram Chamarty Date: Sun, 3 Jun 2012 07:38:19 +0530 Subject: [PATCH] fixup to pushing wild repos permissions... - fix docs to explicitly state that mirroring wild repos is a bad idea if the authentication data is not the same on the peers. - an important check against a malicious peer was missed out. If people heed the warning above this check is not really needed but it is good for completeness. - warning about redirected pushes removed, thanks to Ronald Ip having tested it and reported it working. --- doc/mirroring.mkd | 23 ++++++++++++++--------- src/lib/Gitolite/Triggers/Mirroring.pm | 10 ++++++---- 2 files changed, 20 insertions(+), 13 deletions(-) diff --git a/doc/mirroring.mkd b/doc/mirroring.mkd index 9f88f07..9689c7c 100644 --- a/doc/mirroring.mkd +++ b/doc/mirroring.mkd @@ -41,23 +41,28 @@ Gitolite extends this simple notion in the following ways: prepared to receive updates from the master. However, there is limited support for auto-creating wild card repos and - sending 'perms' info across, with the following caveats at present: + sending 'perms' info across, with the following caveats at present. (Some + of this text won't make sense unless you know what those features are). + + * *WARNING: it does NOT make sense to mirror wild repos in setups where + the authentication data is not the same (i.e., where "alice" on the + master and "alice" on a slave maybe totally different people)*. * This has only been minimally tested. For example, complex setups or asymmetric configs on master and slave, etc. have NOT been tested. - * This has also not been tested with redirected pushes. It may not - work. + * Permission changes will only propagate on the next 'git push'. Of + course, if you know the name of the slave server, you can run + + ssh git@host mirror push slave-server-name repo-name + + * Using 'perms' on a slave is allowed but will neither propagate nor + persist. They will be overwritten by whatever perms the master has + (even if it is an empty set) on the next 'git push'. * As with lots of extra features in gitolite, smart http support is not on my radar. Don't ask. - * If you change permissions using the 'perms' command, they will only go - across on the next push. Or, if you know the name of the slave - server, you can run - - ssh git@host mirror push slave-server-name repo-name - Please test it out and let me know if something surprising happens. Be aware that I have been known to claim bugs are features if I don't have time to fix them immediately :-) diff --git a/src/lib/Gitolite/Triggers/Mirroring.pm b/src/lib/Gitolite/Triggers/Mirroring.pm index bc38781..78d5be9 100644 --- a/src/lib/Gitolite/Triggers/Mirroring.pm +++ b/src/lib/Gitolite/Triggers/Mirroring.pm @@ -17,6 +17,11 @@ my ( $mode, $master, %slaves, %trusted_slaves ); sub input { return unless $ARGV[0] =~ /^server-(\S+)$/; + # note: we treat %rc as our own internal "poor man's %ENV" + $rc{FROM_SERVER} = $1; + trace( 3, "from_server: $1" ); + my $sender = $rc{FROM_SERVER} || ''; + # custom peer-to-peer commands. At present the only one is 'perms -c', # sent from a mirror command if ($ENV{SSH_ORIGINAL_COMMAND} =~ /^CREATOR=(\S+) perms -c '(\S+)'$/) { @@ -26,6 +31,7 @@ sub input { details($repo); _die "$hn: '$repo' is local" if $mode eq 'local'; _die "$hn: '$repo' is native" if $mode eq 'master'; + _die "$hn: '$sender' is not the master for '$repo'" if $master ne $sender; # this expects valid perms content on STDIN _system("gitolite perms -c $repo"); @@ -34,10 +40,6 @@ sub input { exit 0; } - # note: we treat %rc as our own internal "poor man's %ENV" - $rc{FROM_SERVER} = $1; - trace( 3, "from_server: $1" ); - if ( $ENV{SSH_ORIGINAL_COMMAND} =~ /^USER=(\S+) SOC=(git-receive-pack '(\S+)')$/ ) { # my ($user, $newsoc, $repo) = ($1, $2, $3); $ENV{SSH_ORIGINAL_COMMAND} = $2;