deac/gitolite
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity
gitolite/t/t63-perm-cats

208 lines
7.3 KiB
Plaintext
Raw Normal View History

(minor) validate all role names, not just the first line! If you use a role name that was not in GL_WILDREPOS_PERM_CATS, it will get caught later when someone whom youhave given that role tries to access the repo (look for another occurrence of the same error message as this one). So there's no access violation but it would be nice to be told upfront that it won't work.
2012-01-26 01:42:15 +01:00
# vim: ft=sh:
custom perm categories in setperms (WARNING: PLEASE READ FULL COMMIT MESSAGE) THE COMPILED CONFIG FILE FORMAT CHANGES WITH THIS VERSION. PLEASE DO NOT MIX VERSIONS OR DOWNGRADE. Upgrading using normal gitolite upgrade means should be fine, though. Originally, we only allowed "R" and "RW" as categories of users supplied to the `setperms` command. These map respectively to "READERS" and "WRITERS" in the access rules. Now: - we prefer READERS instead of R and WRITERS instead of RW - we allow the admin to define other categories as she wishes (example: MANAGERS, TESTERS, etc). These do not have abbreviations, however, so they must be supplied in full. PLEASE, *PLEASE*, read the section in doc/wildcard-repositories.mkd for more info. This is a VERY powerful feature and if you're not careful you could mess up the ACLs nicely. Backward compat note: you can continue to use the "R" and "RW" categories when running the "setperms" command, and gitolite will internally convert them to READERS and WRITERS categories. ---- implementation notes: - new RC var called GL_WILDREPOS_PERM_CATS that is a space-sep list of the allowed categories in a gl-perms file; defaults to "R RW" if not specified - wild_repo_rights no longer returns $c, $r, $wC, where $r = $user if "R $user", $r = '@all' if "R @all", and similarly with $w and "RW". Instead it returns $c and a new hash that effectively gives the same info, but expanded to include any other valid categories (listed in GL_WILDREPOS_PERM_CATS) - consequently, the arguments that parse_acl takes also change the same way - (side note: R and RW are quietly converted to READERS and WRITERS; however, new categories that you define yourself do not have abbreviations) - setperms validates perms to make sure only allowed categories are used; however even if someone changed them behind the scenes, wild_repo_rights will also check. This is necessary in case the admin tightened up GL_WILDREPOS_PERM_CATS after someone had already setperms-d his repos. - as a bonus, we eliminate all the post-Dumper shenanigans, at least for READERS and WRITERS. Those two now look, to the compile script, just like any other usernames.
2010-11-06 06:16:17 +01:00
# test gl-perms categories
(minor) validate all role names, not just the first line! If you use a role name that was not in GL_WILDREPOS_PERM_CATS, it will get caught later when someone whom youhave given that role tries to access the repo (look for another occurrence of the same error message as this one). So there's no access violation but it would be nice to be told upfront that it won't work.
2012-01-26 01:42:15 +01:00
tsh pwd || die '## tsh not installed?'
custom perm categories in setperms (WARNING: PLEASE READ FULL COMMIT MESSAGE) THE COMPILED CONFIG FILE FORMAT CHANGES WITH THIS VERSION. PLEASE DO NOT MIX VERSIONS OR DOWNGRADE. Upgrading using normal gitolite upgrade means should be fine, though. Originally, we only allowed "R" and "RW" as categories of users supplied to the `setperms` command. These map respectively to "READERS" and "WRITERS" in the access rules. Now: - we prefer READERS instead of R and WRITERS instead of RW - we allow the admin to define other categories as she wishes (example: MANAGERS, TESTERS, etc). These do not have abbreviations, however, so they must be supplied in full. PLEASE, *PLEASE*, read the section in doc/wildcard-repositories.mkd for more info. This is a VERY powerful feature and if you're not careful you could mess up the ACLs nicely. Backward compat note: you can continue to use the "R" and "RW" categories when running the "setperms" command, and gitolite will internally convert them to READERS and WRITERS categories. ---- implementation notes: - new RC var called GL_WILDREPOS_PERM_CATS that is a space-sep list of the allowed categories in a gl-perms file; defaults to "R RW" if not specified - wild_repo_rights no longer returns $c, $r, $wC, where $r = $user if "R $user", $r = '@all' if "R @all", and similarly with $w and "RW". Instead it returns $c and a new hash that effectively gives the same info, but expanded to include any other valid categories (listed in GL_WILDREPOS_PERM_CATS) - consequently, the arguments that parse_acl takes also change the same way - (side note: R and RW are quietly converted to READERS and WRITERS; however, new categories that you define yourself do not have abbreviations) - setperms validates perms to make sure only allowed categories are used; however even if someone changed them behind the scenes, wild_repo_rights will also check. This is necessary in case the admin tightened up GL_WILDREPOS_PERM_CATS after someone had already setperms-d his repos. - as a bonus, we eliminate all the post-Dumper shenanigans, at least for READERS and WRITERS. Those two now look, to the compile script, just like any other usernames.
2010-11-06 06:16:17 +01:00
for bc in 0 1
do
cd $TESTDIR
$TESTDIR/rollback || die "rollback failed"
editrc GL_WILDREPOS 1
editrc GL_BIG_CONFIG $bc
name "INTERNAL"
echo "
@g1 = u1
@g2 = u2
@g3 = u3
@g4 = u4
repo foo/CREATOR/..*
C = @g1
RW+ = CREATOR
- refs/tags/ = WRITERS
RW = WRITERS
R = READERS
RW+D = MANAGERS
RW refs/tags/ = TESTERS
" | ugc
expect "To gitolite:gitolite-admin"
expect "master -> master"
notexpect ABORT
cd ~/td
name "make foo/u1/u1r1"
rm -rf ~/td/u1r1
runlocal git clone u1:foo/u1/u1r1
make REPO_BASE absolute early $ENV{GL_REPO_BASE_ABS} is meant to point to the same directory as $REPO_BASE, except it is meant to be passed to hooks, ADCs and other child programs. And since you can't be sure where the child program starts in, this became an absolute path. Gradually, however, I started using it wherever I needed an absolute path (mostly in code that jumps around various directories to do stuff). Which is silly, because there's no reason $REPO_BASE cannot also be made an absolute, even if the rc file has a relative path. So that's what I did now: made $REPO_BASE absolute very early on, and then systematically changed all uses of the longer form to the shorter form when appropriate. And so the only thing we now use the longer one for is to pass to child programs. (Implementation note: The actual change is not very big, but while I was about it I decided to make the test suite able to test with an absolute REPO_BASE also, which is why the commit seems so large.) ---- This all started with a complaint from Damien Regad. He had an extremely odd setup where his bashrc changed PWD to something other than $HOME before anything else ran. This caused those two variables to beceom inconsistent, and he had a 1-line fix he wanted me to apply. I generally don't like making special fixes for for non-standard setups, and anyway all he had to do was set the full path to REPO_BASE in the rc file to get around this. Which is what I told him and he very politely left it at that. However, this did get me thinking, and I soon realised I was needlessly conflating "relative versus absolute" with "able to be passed to child programs". Fixing that solved his problem also, as a side-effect. So I guess this is all thanks to Damien!
2011-03-18 06:29:52 +01:00
expect "Initialized empty Git repository in $TEST_BASE_FULL/foo/u1/u1r1.git/"
custom perm categories in setperms (WARNING: PLEASE READ FULL COMMIT MESSAGE) THE COMPILED CONFIG FILE FORMAT CHANGES WITH THIS VERSION. PLEASE DO NOT MIX VERSIONS OR DOWNGRADE. Upgrading using normal gitolite upgrade means should be fine, though. Originally, we only allowed "R" and "RW" as categories of users supplied to the `setperms` command. These map respectively to "READERS" and "WRITERS" in the access rules. Now: - we prefer READERS instead of R and WRITERS instead of RW - we allow the admin to define other categories as she wishes (example: MANAGERS, TESTERS, etc). These do not have abbreviations, however, so they must be supplied in full. PLEASE, *PLEASE*, read the section in doc/wildcard-repositories.mkd for more info. This is a VERY powerful feature and if you're not careful you could mess up the ACLs nicely. Backward compat note: you can continue to use the "R" and "RW" categories when running the "setperms" command, and gitolite will internally convert them to READERS and WRITERS categories. ---- implementation notes: - new RC var called GL_WILDREPOS_PERM_CATS that is a space-sep list of the allowed categories in a gl-perms file; defaults to "R RW" if not specified - wild_repo_rights no longer returns $c, $r, $wC, where $r = $user if "R $user", $r = '@all' if "R @all", and similarly with $w and "RW". Instead it returns $c and a new hash that effectively gives the same info, but expanded to include any other valid categories (listed in GL_WILDREPOS_PERM_CATS) - consequently, the arguments that parse_acl takes also change the same way - (side note: R and RW are quietly converted to READERS and WRITERS; however, new categories that you define yourself do not have abbreviations) - setperms validates perms to make sure only allowed categories are used; however even if someone changed them behind the scenes, wild_repo_rights will also check. This is necessary in case the admin tightened up GL_WILDREPOS_PERM_CATS after someone had already setperms-d his repos. - as a bonus, we eliminate all the post-Dumper shenanigans, at least for READERS and WRITERS. Those two now look, to the compile script, just like any other usernames.
2010-11-06 06:16:17 +01:00
cd ~/td/u1r1
name "CREATOR can push"
mdc; mdc
runlocal git push u1:foo/u1/u1r1 master:master
expect_push_ok "master -> master"
name "CREATOR can create branch"
mdc; mdc
runlocal git push u1:foo/u1/u1r1 master:b1
expect_push_ok "master -> b1"
name "CREATOR can rewind branch"
runlocal git reset --hard HEAD^
mdc; mdc
runlocal git push u1:foo/u1/u1r1 +master:b1
expect_push_ok "master -> b1 (forced update)"
name "CREATOR cannot delete branch"
runlocal git push u1:foo/u1/u1r1 :b1
expect "remote: D refs/heads/b1 foo/u1/u1r1 u1 DENIED by fallthru"
expect "remote: error: hook declined to update refs/heads/b1"
expect "\[remote rejected\] b1 (hook declined)"
expect "error: failed to push some refs to 'u1:foo/u1/u1r1'"
name "CREATOR can push a tag"
git tag t1 HEAD^^
runlocal git push u1:foo/u1/u1r1 t1
expect_push_ok "\[new tag\] t1 -> t1"
name "add u2 to WRITERS"
echo WRITERS @g2 | runlocal ssh u1 setperms foo/u1/u1r1
runlocal ssh u1 getperms foo/u1/u1r1
expect "WRITERS @g2"
runlocal git fetch
runlocal git reset --hard origin/master
name "WRITERS can push"
mdc; mdc
runlocal git push u2:foo/u1/u1r1 master:master
expect_push_ok "master -> master"
name "WRITERS can create branch"
mdc; mdc
runlocal git push u2:foo/u1/u1r1 master:b2
expect_push_ok "master -> b2"
name "WRITERS cannot rewind branch"
runlocal git reset --hard HEAD^
mdc; mdc
runlocal git push u2:foo/u1/u1r1 +master:b2
expect "remote: + refs/heads/b2 foo/u1/u1r1 u2 DENIED by fallthru"
expect "remote: error: hook declined to update refs/heads/b2"
expect "\[remote rejected\] master -> b2 (hook declined)"
expect "error: failed to push some refs to 'u2:foo/u1/u1r1'"
name "WRITERS cannot delete branch"
runlocal git push u2:foo/u1/u1r1 :b2
expect "remote: D refs/heads/b2 foo/u1/u1r1 u2 DENIED by fallthru"
expect "remote: error: hook declined to update refs/heads/b2"
expect "\[remote rejected\] b2 (hook declined)"
expect "error: failed to push some refs to 'u2:foo/u1/u1r1'"
name "WRITERS cannot push a tag"
git tag t2 HEAD^^
runlocal git push u2:foo/u1/u1r1 t2
make all the DENIED messages consistent how did I not notice this before?
2011-10-18 04:33:05 +02:00
expect "remote: W refs/tags/t2 foo/u1/u1r1 u2 DENIED by refs/tags/"
custom perm categories in setperms (WARNING: PLEASE READ FULL COMMIT MESSAGE) THE COMPILED CONFIG FILE FORMAT CHANGES WITH THIS VERSION. PLEASE DO NOT MIX VERSIONS OR DOWNGRADE. Upgrading using normal gitolite upgrade means should be fine, though. Originally, we only allowed "R" and "RW" as categories of users supplied to the `setperms` command. These map respectively to "READERS" and "WRITERS" in the access rules. Now: - we prefer READERS instead of R and WRITERS instead of RW - we allow the admin to define other categories as she wishes (example: MANAGERS, TESTERS, etc). These do not have abbreviations, however, so they must be supplied in full. PLEASE, *PLEASE*, read the section in doc/wildcard-repositories.mkd for more info. This is a VERY powerful feature and if you're not careful you could mess up the ACLs nicely. Backward compat note: you can continue to use the "R" and "RW" categories when running the "setperms" command, and gitolite will internally convert them to READERS and WRITERS categories. ---- implementation notes: - new RC var called GL_WILDREPOS_PERM_CATS that is a space-sep list of the allowed categories in a gl-perms file; defaults to "R RW" if not specified - wild_repo_rights no longer returns $c, $r, $wC, where $r = $user if "R $user", $r = '@all' if "R @all", and similarly with $w and "RW". Instead it returns $c and a new hash that effectively gives the same info, but expanded to include any other valid categories (listed in GL_WILDREPOS_PERM_CATS) - consequently, the arguments that parse_acl takes also change the same way - (side note: R and RW are quietly converted to READERS and WRITERS; however, new categories that you define yourself do not have abbreviations) - setperms validates perms to make sure only allowed categories are used; however even if someone changed them behind the scenes, wild_repo_rights will also check. This is necessary in case the admin tightened up GL_WILDREPOS_PERM_CATS after someone had already setperms-d his repos. - as a bonus, we eliminate all the post-Dumper shenanigans, at least for READERS and WRITERS. Those two now look, to the compile script, just like any other usernames.
2010-11-06 06:16:17 +01:00
expect "remote: error: hook declined to update refs/tags/t2"
expect "\[remote rejected\] t2 -> t2 (hook declined)"
expect "error: failed to push some refs to 'u2:foo/u1/u1r1'"
name "change u2 to READERS"
echo READERS u2 | runlocal ssh u1 setperms foo/u1/u1r1
runlocal ssh u1 getperms foo/u1/u1r1
expect "READERS u2"
runlocal git fetch
runlocal git reset --hard origin/master
name "READERS cannot push at all"
mdc; mdc
runlocal git push u2:foo/u1/u1r1 master:master
expect "W access for foo/u1/u1r1 DENIED to u2"
name "add invalid category MANAGERS"
(minor) validate all role names, not just the first line! If you use a role name that was not in GL_WILDREPOS_PERM_CATS, it will get caught later when someone whom youhave given that role tries to access the repo (look for another occurrence of the same error message as this one). So there's no access violation but it would be nice to be told upfront that it won't work.
2012-01-26 01:42:15 +01:00
tsh "
( echo READERS u6\; echo MANAGERS u2 ) | ssh u1 setperms foo/u1/u1r1;
!ok; /invalid permission category MANAGERS/
"
custom perm categories in setperms (WARNING: PLEASE READ FULL COMMIT MESSAGE) THE COMPILED CONFIG FILE FORMAT CHANGES WITH THIS VERSION. PLEASE DO NOT MIX VERSIONS OR DOWNGRADE. Upgrading using normal gitolite upgrade means should be fine, though. Originally, we only allowed "R" and "RW" as categories of users supplied to the `setperms` command. These map respectively to "READERS" and "WRITERS" in the access rules. Now: - we prefer READERS instead of R and WRITERS instead of RW - we allow the admin to define other categories as she wishes (example: MANAGERS, TESTERS, etc). These do not have abbreviations, however, so they must be supplied in full. PLEASE, *PLEASE*, read the section in doc/wildcard-repositories.mkd for more info. This is a VERY powerful feature and if you're not careful you could mess up the ACLs nicely. Backward compat note: you can continue to use the "R" and "RW" categories when running the "setperms" command, and gitolite will internally convert them to READERS and WRITERS categories. ---- implementation notes: - new RC var called GL_WILDREPOS_PERM_CATS that is a space-sep list of the allowed categories in a gl-perms file; defaults to "R RW" if not specified - wild_repo_rights no longer returns $c, $r, $wC, where $r = $user if "R $user", $r = '@all' if "R @all", and similarly with $w and "RW". Instead it returns $c and a new hash that effectively gives the same info, but expanded to include any other valid categories (listed in GL_WILDREPOS_PERM_CATS) - consequently, the arguments that parse_acl takes also change the same way - (side note: R and RW are quietly converted to READERS and WRITERS; however, new categories that you define yourself do not have abbreviations) - setperms validates perms to make sure only allowed categories are used; however even if someone changed them behind the scenes, wild_repo_rights will also check. This is necessary in case the admin tightened up GL_WILDREPOS_PERM_CATS after someone had already setperms-d his repos. - as a bonus, we eliminate all the post-Dumper shenanigans, at least for READERS and WRITERS. Those two now look, to the compile script, just like any other usernames.
2010-11-06 06:16:17 +01:00
name "add u2 to now valid MANAGERS"
echo "\$GL_WILDREPOS_PERM_CATS = 'READERS WRITERS MANAGERS';" | addrc
(minor) validate all role names, not just the first line! If you use a role name that was not in GL_WILDREPOS_PERM_CATS, it will get caught later when someone whom youhave given that role tries to access the repo (look for another occurrence of the same error message as this one). So there's no access violation but it would be nice to be told upfront that it won't work.
2012-01-26 01:42:15 +01:00
tsh "
( echo READERS u6\; echo MANAGERS u2 ) | ssh u1 setperms foo/u1/u1r1;
ok; !/invalid permission category MANAGERS/
/New perms are:/
/READERS u6/
/MANAGERS u2/
"
custom perm categories in setperms (WARNING: PLEASE READ FULL COMMIT MESSAGE) THE COMPILED CONFIG FILE FORMAT CHANGES WITH THIS VERSION. PLEASE DO NOT MIX VERSIONS OR DOWNGRADE. Upgrading using normal gitolite upgrade means should be fine, though. Originally, we only allowed "R" and "RW" as categories of users supplied to the `setperms` command. These map respectively to "READERS" and "WRITERS" in the access rules. Now: - we prefer READERS instead of R and WRITERS instead of RW - we allow the admin to define other categories as she wishes (example: MANAGERS, TESTERS, etc). These do not have abbreviations, however, so they must be supplied in full. PLEASE, *PLEASE*, read the section in doc/wildcard-repositories.mkd for more info. This is a VERY powerful feature and if you're not careful you could mess up the ACLs nicely. Backward compat note: you can continue to use the "R" and "RW" categories when running the "setperms" command, and gitolite will internally convert them to READERS and WRITERS categories. ---- implementation notes: - new RC var called GL_WILDREPOS_PERM_CATS that is a space-sep list of the allowed categories in a gl-perms file; defaults to "R RW" if not specified - wild_repo_rights no longer returns $c, $r, $wC, where $r = $user if "R $user", $r = '@all' if "R @all", and similarly with $w and "RW". Instead it returns $c and a new hash that effectively gives the same info, but expanded to include any other valid categories (listed in GL_WILDREPOS_PERM_CATS) - consequently, the arguments that parse_acl takes also change the same way - (side note: R and RW are quietly converted to READERS and WRITERS; however, new categories that you define yourself do not have abbreviations) - setperms validates perms to make sure only allowed categories are used; however even if someone changed them behind the scenes, wild_repo_rights will also check. This is necessary in case the admin tightened up GL_WILDREPOS_PERM_CATS after someone had already setperms-d his repos. - as a bonus, we eliminate all the post-Dumper shenanigans, at least for READERS and WRITERS. Those two now look, to the compile script, just like any other usernames.
2010-11-06 06:16:17 +01:00
runlocal git fetch
runlocal git reset --hard origin/master
name "MANAGERS can push"
mdc; mdc
runlocal git push u2:foo/u1/u1r1 master:master
expect_push_ok "master -> master"
name "MANAGERS can create branch"
mdc; mdc
runlocal git push u2:foo/u1/u1r1 master:b3
expect_push_ok "master -> b3"
name "MANAGERS can rewind branch"
runlocal git reset --hard HEAD^
mdc; mdc
runlocal git push u2:foo/u1/u1r1 +master:b3
expect_push_ok "master -> b3 (forced update)"
name "MANAGERS cannot delete branch"
runlocal git push u2:foo/u1/u1r1 :b3
expect " - \[deleted\] b3"
name "MANAGERS can push a tag"
git tag t3 HEAD^^
runlocal git push u2:foo/u1/u1r1 t3
expect_push_ok "\[new tag\] t3 -> t3"
name "add invalid category TESTERS"
echo TESTERS u2 | runlocal ssh u1 setperms foo/u1/u1r1
expect "invalid permission category TESTERS"
name "add u2 to now valid TESTERS"
echo "\$GL_WILDREPOS_PERM_CATS = 'READERS WRITERS TESTERS';" | addrc
echo TESTERS u2 | runlocal ssh u1 setperms foo/u1/u1r1
notexpect "invalid permission category TESTERS"
expect "New perms are:"
expect "TESTERS u2"
runlocal git fetch
runlocal git reset --hard origin/master
name "TESTERS cannot push"
mdc; mdc
runlocal git push u2:foo/u1/u1r1 master:master
expect "remote: W refs/heads/master foo/u1/u1r1 u2 DENIED by fallthru"
expect "remote: error: hook declined to update refs/heads/master"
expect "\[remote rejected\] master -> master (hook declined)"
expect "error: failed to push some refs to 'u2:foo/u1/u1r1'"
name "TESTERS cannot create branch"
mdc; mdc
runlocal git push u2:foo/u1/u1r1 master:b4
expect "remote: W refs/heads/b4 foo/u1/u1r1 u2 DENIED by fallthru"
expect "remote: error: hook declined to update refs/heads/b4"
expect "\[remote rejected\] master -> b4 (hook declined)"
expect "error: failed to push some refs to 'u2:foo/u1/u1r1'"
name "TESTERS cannot delete branch"
runlocal git push u2:foo/u1/u1r1 :b2
expect "remote: D refs/heads/b2 foo/u1/u1r1 u2 DENIED by fallthru"
expect "remote: error: hook declined to update refs/heads/b2"
expect "\[remote rejected\] b2 (hook declined)"
expect "error: failed to push some refs to 'u2:foo/u1/u1r1'"
name "TESTERS can push a tag"
git tag t4 HEAD^^
runlocal git push u2:foo/u1/u1r1 t4
expect_push_ok "\[new tag\] t4 -> t4"
name "make TESTERS invalid again"
echo "\$GL_WILDREPOS_PERM_CATS = 'READERS WRITERS MANAGERS';" | addrc
name "CREATOR can push"
runlocal git fetch
runlocal git reset --hard origin/master
mdc; mdc
runlocal git push u1:foo/u1/u1r1 master:master
expect_push_ok "master -> master"
name "TESTERS is an invalid category"
git tag t5 HEAD^^
runlocal git push u2:foo/u1/u1r1 t5
expect "invalid permission category TESTERS"
name "INTERNAL"
done
Reference in a new issue Copy permalink