Permalink
Browse files

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.
  • Loading branch information...
1 parent 78866f6 commit db70595b877c669dacf52f0fbf59a6f4c29e08c1 @sitaramc committed Jun 3, 2012
Showing with 20 additions and 13 deletions.
  1. +14 −9 doc/mirroring.mkd
  2. +6 −4 src/lib/Gitolite/Triggers/Mirroring.pm
View
@@ -41,22 +41,27 @@ 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
- * As with lots of extra features in gitolite, smart http support is not
- on my radar. Don't ask.
+ ssh git@host mirror push slave-server-name repo-name
- * 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
+ * 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'.
- ssh git@host mirror push slave-server-name repo-name
+ * As with lots of extra features in gitolite, smart http support is not
+ on my radar. Don't ask.
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
@@ -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;

0 comments on commit db70595

Please sign in to comment.