contrib/t/ukm.t

   1 #!/usr/bin/perl
   2
   3 # Call like this:
   4 # TSH_VERBOSE=1 TSH_ERREXIT=1 HARNESS_ACTIVE=1 GITOLITE_TEST=y prove t/ukm.t
   5
   6 use strict;
   7 use warnings;
   8
   9 # this is hardcoded; change it if needed
  10 use lib "src/lib";
  11 use Gitolite::Common;
  12 use Gitolite::Test;
  13
  14 # basic tests using ssh
  15 # ----------------------------------------------------------------------
  16
  17 my $bd = `gitolite query-rc -n GL_BINDIR`;
  18 my $h  = $ENV{HOME};
  19 my $ab = `gitolite query-rc -n GL_ADMIN_BASE`;
  20 my $pd = "$bd/../t/keys"; # source for pubkeys
  21 umask 0077;
  22
  23 _mkdir( "$h/.ssh", 0700 ) if not -d "$h/.ssh";
  24
  25 try "plan 204";
  26
  27
  28 # Reset everything.
  29 # Only admin and u1, u2, and u3 keys are available initially
  30 # Keys u4, u5, and u6 are used as guests later.
  31 # For easy access, we put the keys into ~/.ssh/, though.
  32 try "
  33     rm -f $h/.ssh/authorized_keys; ok or die 1
  34     cp $pd/u[1-6]* $h/.ssh; ok or die 2
  35     cp $pd/admin*  $h/.ssh; ok or die 3
  36     cp $pd/config  $h/.ssh; ok or die 4
  37         cat $h/.ssh/config
  38         perl s/%USER/$ENV{USER}/
  39         put $h/.ssh/config
  40     mkdir             $ab/keydir; ok or die 5
  41     cp $pd/u[1-3].pub $ab/keydir; ok or die 6
  42     cp $pd/admin.pub  $ab/keydir; ok or die 7
  43 ";
  44
  45 # Put the keys into ~/.ssh/authorized_keys
  46 system("gitolite ../triggers/post-compile/ssh-authkeys");
  47
  48 # enable user key management in a simple form.
  49 # Guest key managers can add keyids looking like email addresses, but
  50 # cannot add emails containing example.com or hemmecke.org.
  51 system("sed -i \"s/.*ENABLE =>.*/'UKM_CONFIG'=>{'FORBIDDEN_GUEST_PATTERN'=>'example.com|hemmecke.org'}, ENABLE => ['ukm',/\" $h/.gitolite.rc");
  52
  53 # super-key-managers can add/del any key
  54 # super-key-managers should in fact agree with people having write
  55 # access to gitolite-admin repo.
  56 # guest-key-managers can add/del guest keys
  57 confreset; confadd '
  58     @guest-key-managers = u2 u3
  59     @creators = u2 u3
  60     repo pub/CREATOR/..*
  61         C   =   @creators
  62         RW+ =   CREATOR
  63         RW  =   WRITERS
  64         R   =   READERS
  65 ';
  66
  67 # Populate the gitolite-admin/keydir in the same way as it was used for
  68 # the initialization of .ssh/authorized_keys above.
  69 try "
  70     mkdir             keydir; ok or die 8
  71     cp $pd/u[1-3].pub keydir; ok or die 9;
  72     cp $pd/admin.pub  keydir; ok or die 10;
  73     git add conf keydir; ok
  74     git commit -m ukm; ok; /master.* ukm/
  75 ";
  76
  77 # Activate new config data.
  78 try "PUSH admin; ok; gsh; /master -> master/; !/FATAL/" or die text();
  79
  80 # Check whether the above setup yields the expected behavior for ukm.
  81 # The admin is super-key-manager, thus can manage every key.
  82 try "
  83     ssh admin ukm; ok; /Hello admin, you manage the following keys:/
  84                        / admin +admin/
  85                        / u1 +u1/
  86                        / u2 +u2/
  87                        / u3 +u3/
  88 ";
  89
  90 # u1 isn't a key manager, so shouldn't be above to manage keys.
  91 try "ssh u1 ukm; !ok; /FATAL: You are not a key manager./";
  92
  93 # u2 and u3 are guest key managers, but don't yet manage any key.
  94 try "ssh u2 ukm; ok"; cmp "Hello u2, you manage the following keys:\n\n\n";
  95 try "ssh u3 ukm; ok"; cmp "Hello u3, you manage the following keys:\n\n\n";
  96
  97
  98 ###################################################################
  99 # Unknows subkommands abort ukm.
 100 try "ssh u2 ukm fake; !ok; /FATAL: unknown ukm subcommand: fake/";
 101
 102
 103 ###################################################################
 104 # Addition of keys.
 105
 106 # If no data is provided on stdin, we don't block, but rather timeout
 107 # after one second and abort the program.
 108 try "ssh u2 ukm add u4\@example.org; !ok; /FATAL: missing public key data/";
 109
 110 # If no keyid is given, we cannot add a key.
 111 try "ssh u2 ukm add; !ok; /FATAL: keyid required/";
 112
 113 try "
 114     DEF ADD = cat $pd/%1.pub|ssh %2 ukm add %3
 115     DEF ADDOK = ADD %1 %2 %3; ok
 116     DEF ADDNOK = ADD %1 %2 %3; !ok
 117     DEF FP = ADDNOK u4 u2 %1
 118     DEF FORBIDDEN_PATTERN = FP %1; /FATAL: keyid not allowed:/
 119 ";
 120
 121 # Neither a guest key manager nor a super key manager can add keys that have
 122 # double dot in their keyid. This is hardcoded to forbid paths with .. in it.
 123 try "
 124     ADDNOK u4 u2    u4\@hemmecke..org; /Not allowed to use '..' in keyid./
 125     ADDNOK u4 admin u4\@hemmecke..org; /Not allowed to use '..' in keyid./
 126     ADDNOK u4 admin ./../.myshrc;      /Not allowed to use '..' in keyid./
 127 ";
 128
 129 # guest-key-managers can only add keys that look like emails.
 130 try "
 131     FORBIDDEN_PATTERN u4
 132     FORBIDDEN_PATTERN u4\@example
 133     FORBIDDEN_PATTERN u4\@foo\@example.org
 134
 135     # No support for 'old style' multiple keys.
 136     FORBIDDEN_PATTERN u4\@example.org\@foo
 137
 138     # No path delimiter in keyid
 139     FORBIDDEN_PATTERN foo/u4\@example.org
 140
 141     # Certain specific domains listed in FORBIDDEN_GUEST_PATTERN are forbidden.
 142     # Note that also u4\@example-com would be rejected, because MYDOMAIN
 143     # contains a regular expression --> I don't care.
 144     FORBIDDEN_PATTERN u4\@example.com
 145     FORBIDDEN_PATTERN u4\@hemmecke.org
 146 ";
 147
 148 # Accept one guest key.
 149 try "ADDOK u4 u2 u4\@example.org";
 150 try "ssh u2 ukm; ok; /Hello u2, you manage the following keys:/
 151                      / u4\@example.org *u4\@example.org/";
 152
 153 # Various ways how a key must be rejected.
 154 try "
 155     # Cannot add the same key again.
 156     ADDNOK u4 u2 u4\@example.org; /FATAL: cannot override existing key/
 157
 158     # u2 can also not add u4.pub under another keyid
 159     ADDNOK u4 u2 u4\@example.net; /FATAL: cannot add key/
 160          /Same key is already available under another userid./
 161
 162     # u2 can also not add another key under the same keyid.
 163     ADDNOK u5 u2 u4\@example.org; /FATAL: cannot override existing key/
 164
 165     # Also u3 cannot not add another key under the same keyid.
 166     ADDNOK u5 u3 u4\@example.org
 167          /FATAL: cannot add another public key for an existing user/
 168
 169     # And u3 cannot not add u4.pub under another keyid.
 170     ADDNOK u4 u3 u4\@example.net; /FATAL: cannot add key/
 171          /Same key is already available under another userid./
 172
 173     # Not even the admin can add the same key u4 under a different userid.
 174     ADDNOK u4 admin u4\@example.net; /FATAL: cannot add key/
 175          /Same key is already available under another userid./
 176          /Found  .* u4\@example.org/
 177
 178     # Super key managers cannot add keys that start with @.
 179     # We don't care about @ in the dirname, though.
 180     ADDNOK u4 admin foo/\@ex.net; /FATAL: cannot add key that starts with \@/
 181     ADDNOK u4 admin foo/\@ex;     /FATAL: cannot add key that starts with \@/
 182     ADDNOK u4 admin     \@ex.net; /FATAL: cannot add key that starts with \@/
 183     ADDNOK u4 admin     \@ex;     /FATAL: cannot add key that starts with \@/
 184 ";
 185
 186 # But u3 can add u4.pub under the same keyid.
 187 try "ADDOK u4 u3 u4\@example.org";
 188
 189 try "ssh u3 ukm; ok; /Hello u3, you manage the following keys:/
 190                      / u4\@example.org *u4\@example.org/";
 191
 192 # The admin can add multiple keys for the same userid.
 193 try "
 194     ADDOK u5 admin u4\@example.org
 195     ADDOK u5 admin u4\@example.org\@home
 196     ADDOK u5 admin laptop/u4\@example.org
 197     ADDOK u5 admin laptop/u4\@example.org\@home
 198 ";
 199
 200 # And admin can also do this for other guest key managers. Note,
 201 # however, that the gitolite-admin must be told where the
 202 # GUEST_DIRECTORY is. But he/she could find out by cloning the
 203 # gitolite-admin repository and adding the same key directly.
 204 try "
 205     ADDOK u5 admin zzz/guests/u2/u4\@example.org\@foo
 206     ADDOK u6 admin zzz/guests/u3/u6\@example.org
 207 ";
 208
 209 try "ssh admin ukm; ok"; cmp "Hello admin, you manage the following keys:
 210 fingerprint                                     userid         keyid
 211 a4:d1:11:1d:25:5c:55:9b:5f:91:37:0e:44:a5:a5:f2 admin          admin
 212 00:2c:1f:dd:a3:76:5a:1e:c4:3c:01:15:65:19:a5:2e u1             u1
 213 69:6f:b5:8a:f5:7b:d8:40:ce:94:09:a2:b8:95:79:5b u2             u2
 214 26:4b:20:24:98:a4:e4:a5:b9:97:76:9a:15:92:27:2d u3             u3
 215 78:cf:7e:2b:bf:18:58:54:23:cc:4b:3d:7e:f4:63:79 u4\@example.org laptop/u4\@example.org
 216 78:cf:7e:2b:bf:18:58:54:23:cc:4b:3d:7e:f4:63:79 u4\@example.org laptop/u4\@example.org\@home
 217 78:cf:7e:2b:bf:18:58:54:23:cc:4b:3d:7e:f4:63:79 u4\@example.org u4\@example.org
 218 78:cf:7e:2b:bf:18:58:54:23:cc:4b:3d:7e:f4:63:79 u4\@example.org u4\@example.org\@home
 219 8c:a6:c0:a5:71:85:0b:89:d3:08:97:22:ae:95:e1:bb u4\@example.org zzz/guests/u2/u4\@example.org
 220 78:cf:7e:2b:bf:18:58:54:23:cc:4b:3d:7e:f4:63:79 u4\@example.org zzz/guests/u2/u4\@example.org\@foo
 221 8c:a6:c0:a5:71:85:0b:89:d3:08:97:22:ae:95:e1:bb u4\@example.org zzz/guests/u3/u4\@example.org
 222 fc:0f:eb:52:7a:d2:35:da:89:96:f5:15:0e:85:46:e7 u6\@example.org zzz/guests/u3/u6\@example.org
 223 \n\n";
 224
 225 # Now, u2 has two keys in his directory, but u2 can manage only one of
 226 # them, since the one added by the admin has two @ in it. Thus the key
 227 # added by admin is invisible to u2.
 228 try "ssh u2 ukm; ok"; cmp "Hello u2, you manage the following keys:
 229 fingerprint                                     userid         keyid
 230 8c:a6:c0:a5:71:85:0b:89:d3:08:97:22:ae:95:e1:bb u4\@example.org u4\@example.org
 231 \n\n";
 232
 233 # Since admin added key u6@example.org to the directory of u2, u2 is
 234 # also able to see it and, in fact, to manage it.
 235 try "ssh u3 ukm; ok"; cmp "Hello u3, you manage the following keys:
 236 fingerprint                                     userid         keyid
 237 8c:a6:c0:a5:71:85:0b:89:d3:08:97:22:ae:95:e1:bb u4\@example.org u4\@example.org
 238 fc:0f:eb:52:7a:d2:35:da:89:96:f5:15:0e:85:46:e7 u6\@example.org u6\@example.org
 239 \n\n";
 240
 241 ###################################################################
 242 # Deletion of keys.
 243 try "
 244     DEF DEL = ssh %1 ukm del %2
 245     DEF DELOK  = DEL %1 %2; ok
 246     DEF DELNOK = DEL %1 %2; !ok
 247     DEF DELNOMGR = DELNOK %1 %2; /FATAL: You are not managing the key /
 248 ";
 249
 250 # Deletion requires a keyid.
 251 try "ssh u3 ukm del; !ok; /FATAL: keyid required/";
 252
 253 # u3 can, of course, not remove any unmanaged key.
 254 try "DELNOMGR u3 u2";
 255
 256 # But u3 can delete u4@example.org and u6@example.org. This will, of course,
 257 # not remove the key u4@example.org that u2 manages.
 258 try "
 259     DELOK u3 u4\@example.org
 260     DELOK u3 u6\@example.org
 261 ";
 262
 263 # After having deleted u4@example.org, u3 cannot remove it again,
 264 # even though, u2 still manages that key.
 265 try "DELNOMGR u3 u4\@example.org";
 266
 267 # Of course a super-key-manager can remove any (existing) key.
 268 try "
 269     DELOK  admin zzz/guests/u2/u4\@example.org
 270     DELNOK admin zzz/guests/u2/u4\@example.org
 271         /FATAL: You are not managing the key zzz/guests/u2/u4\@example.org./
 272     DELNOK admin zzz/guests/u2/u4\@example.org\@x
 273         /FATAL: You are not managing the key zzz/guests/u2/u4\@example.org./
 274     DELOK  admin zzz/guests/u2/u4\@example.org\@foo
 275 ";
 276
 277 # As the admin could do that via pushing to the gitolite-admin manually,
 278 # it's also allowed to delete even non-guest keys.
 279 try "DELOK admin u3";
 280
 281 # Let's clean the environment again.
 282 try "
 283     DELOK admin laptop/u4\@example.org\@home
 284     DELOK admin laptop/u4\@example.org
 285     DELOK admin        u4\@example.org\@home
 286     DELOK admin        u4\@example.org
 287     ADDOK u3 admin u3
 288  ";
 289
 290 # Currently the admin has just one key. It cannot be removed.
 291 # But after adding another key, deletion should work fine.
 292 try "
 293     DELNOK admin admin; /FATAL: You cannot delete your last key./
 294     ADDOK u6 admin second/admin; /Adding new public key for admin./
 295     DELOK admin admin
 296     DELNOK u6 admin; /FATAL: You are not managing the key admin./
 297     DELNOK u6 second/admin; /FATAL: You cannot delete your last key./
 298     ADDOK admin u6 admin; /Adding new public key for admin./
 299     DELOK u6 second/admin
 300 ";
 301
 302 ###################################################################
 303 # Selfkey management.
 304
 305 # If self key management is not switched on in the .gitolite.rc file,
 306 # it's not allowed at all.
 307 try "ssh u2 ukm add \@second; !ok; /FATAL: selfkey management is not enabled/";
 308
 309 # Let's enable it.
 310 system("sed -i \"/'UKM_CONFIG'=>/s/=>{/=>{'SELFKEY_MANAGEMENT'=>1,/\" $h/.gitolite.rc");
 311
 312 # And add self-key-managers to gitolite.conf
 313 # chdir("../gitolite-admin") or die "in `pwd`, could not cd ../g-a";
 314 try "glt pull admin origin master; ok";
 315 put "|cut -c5- > conf/gitolite.conf", '
 316     repo gitolite-admin
 317         RW+ = admin
 318     repo testing
 319         RW+ = @all
 320     @guest-key-managers = u2 u3
 321     @self-key-managers = u1 u2
 322     @creators = u2 u3
 323     repo pub/CREATOR/..*
 324         C   =   @creators
 325         RW+ =   CREATOR
 326         RW  =   WRITERS
 327         R   =   READERS
 328 ';
 329 try "
 330     git add conf keydir; ok
 331     git commit -m selfkey; ok; /master.* selfkey/
 332 ";
 333 try "PUSH admin; ok; gsh; /master -> master/; !/FATAL/" or die text();
 334
 335 # Now we can start with the tests.
 336
 337 # Only self key managers are allowed to use selfkey management.
 338 # See variable @self-key-managers.
 339 try "ssh u3 ukm add \@second; !ok; /FATAL: You are not a selfkey manager./";
 340
 341 # Cannot add keyid that are not alphanumeric.
 342 try "ssh u1 ukm add \@second-key; !ok; /FATAL: keyid not allowed:/";
 343
 344 # Add a second key for u1, but leave it pending by not feeding in the
 345 # session key. The new user can login, but he/she lives under a quite
 346 # random gl_user name and thus is pretty much excluded from everything
 347 # except permissions given to @all. If this new id calls ukm without
 348 # providing the session key, this (pending) key is automatically
 349 # removed from the system.
 350 # If a certain keyid is in the system, then it cannot be added again.
 351 try "
 352     ADDOK u4 u1 \@second
 353     ssh admin ukm; ok; /u1     zzz/self/u1/zzz-add-[a-z0-9]{32}-second-u1/
 354     ssh u1    ukm; ok; /u1     \@second .pending add./
 355     ADDNOK u4 u1 \@second; /FATAL: keyid already in use: \@second/
 356     ssh u4    ukm; ok; /pending keyid deleted: \@second/
 357     ssh admin ukm; ok; !/zzz/; !/second/
 358 ";
 359
 360 # Not providing a proper ssh public key will abort. Providing a good
 361 # ssh public key, which is not a session key makes the key invalid.
 362 # The key will, therefore, be deleted by this operation.
 363 try "
 364     ADDOK u4 u1 \@second
 365     echo fake|ssh u4 ukm; !ok; /FATAL: does not seem to be a valid pubkey/
 366     cat $pd/u5.pub | ssh u4 ukm; ok;
 367         /session key not accepted/
 368         /pending keyid deleted: \@second/
 369 ";
 370
 371 # True addition of a new selfkey is done via piping it to a second ssh
 372 # call that uses the new key to call ukm. Note that the first ssh must
 373 # have completed its job before the second ssh is able to successfully
 374 # log in. This can be done via sleep or via redirecting to a file and
 375 # then reading from it.
 376 try "
 377     # ADDOK u4 u1 \@second | (sleep 2; ssh u4 ukm); ok
 378     ADD u4 u1 \@second > session; ok
 379     cat session | ssh u4 ukm; ok;  /pending keyid added: \@second/
 380 ";
 381
 382 # u1 cannot add his/her initial key, since that key can never be
 383 # confirmed via ukm, so it is forbidden altogether. In fact, u1 is not
 384 # allowed to add any key twice.
 385 try "
 386     ADDNOK u1 u1 \@first
 387        /FATAL: You cannot add a key that already belongs to you./
 388     ADDNOK u4 u1 \@first
 389        /FATAL: You cannot add a key that already belongs to you./
 390 ";
 391
 392 # u1 also can add more keys, but not under an existing keyid. That can
 393 # be done by any of his/her identities (here we choose u4).
 394 try "
 395     ADDNOK u5 u1 \@second; /FATAL: keyid already in use: \@second/
 396     ADD u5 u4 \@third > session; ok
 397     cat session | ssh u5 ukm; ok;  /pending keyid added: \@third/
 398 ";
 399
 400 # u2 cannot add the same key, but is allowed to use the same name (@third).
 401 try "
 402     ADDNOK u5 u2 \@third; /FATAL: cannot add key/
 403         /Same key is already available under another userid./
 404     ADD u6 u2 \@third > session; ok
 405     cat session | ssh u6 ukm; ok;  /pending keyid added: \@third/
 406 ";
 407
 408 # u6 can schedule his/her own key for deletion, but cannot actually
 409 # remove it. Trying to do so results in bringing back the key. Actual
 410 # deletion must be confirmed by another key.
 411 try "
 412     ssh u6 ukm del \@third; /prepare deletion of key \@third/
 413     ssh u2 ukm; ok; /u2     \@third .pending del./
 414     ssh u6 ukm; ok; /undo pending deletion of keyid \@third/
 415     ssh u6 ukm del \@third; /prepare deletion of key \@third/
 416     ssh u2 ukm del \@third; ok;  /pending keyid deleted: \@third/
 417 ";
 418
 419 # While in pending-deletion state, it's forbidden to add another key
 420 # with the same keyid. It's also forbidden to add a key with the same
 421 # fingerprint as the to-be-deleted key).
 422 # A new key under another keyid, is OK.
 423 try "
 424     ssh u1 ukm del \@third; /prepare deletion of key \@third/
 425     ADDNOK u4 u1 \@third; /FATAL: keyid already in use: \@third/
 426     ADDNOK u5 u1 \@fourth;
 427         /FATAL: You cannot add a key that already belongs to you./
 428     ADD u6 u1 \@fourth > session; ok
 429     ssh u1 ukm; ok;
 430         /u1     \@second/
 431         /u1     \@fourth .pending add./
 432         /u1     \@third .pending del./
 433 ";
 434 # We can remove a pending-for-addition key (@fourth) by logging in
 435 # with a non-pending key. Trying to do anything with key u5 (@third)
 436 # will just bring it back to its normal state, but not change the
 437 # state of any other key. As already shown above, using u6 (@fourth)
 438 # without a proper session key, would remove it from the system.
 439 # Here we want to demonstrate that key u1 can delete u6 immediately.
 440 try "ssh u1 ukm del \@fourth; /pending keyid deleted: \@fourth/";
 441
 442 # The pending-for-deletion key @third can also be removed via the u4
 443 # (@second) key.
 444 try "ssh u4 ukm del \@third; ok; /pending keyid deleted: \@third/";
 445
 446 # Non-existing selfkeys cannot be deleted.
 447 try "ssh u4 ukm del \@x; !ok; /FATAL: You are not managing the key \@x./";