What happens is that running
ssh git@host perms reponame
appears to hang, since it is waiting for STDIN. I added a message to
help, since we don't want users losing files accidentally!
(The other alternative is to add a specific option for batch mode, but
this is backward incompatible for people who have scripts that may be
doing this).
thanks to Caleb Cushing for catching this
----
The "make sure Ctrl-C gets caught" thing needs some explanation.
Without it, a user could inadvertently lose his gl-perms file if he ran
the command in batch mode. You'd think that the Ctrl-C would hit the
for (<>) {
line and bail, but it manages to reach the
_print( $pf, @a );
line somehow. Even trapping SIG INT does not help.
I suspect it is to do with how signals are propagated by ssh across a
"no-pty" session, but am not sure.
Sometime after v3.2, I fixed what looked like an information disclosure
issue, where a user could determine if an arbitrary repo existed or not,
even if he had no rights to see the repo. This was:
96cc2ea "new features relating to creating wild repos:"
Unfortunately, this appears to have broken gl-perms propagation to
slaves, because now running "perm -c" on an existing repo dies!
If you run
git diff 96cc2ea^ <this commit> -- src/commands/perms
you'll see how simple the fix *should* have been :-(
Still, I would advise caution if you use this as a basis for deleting
repos from the file system. A bug in this program could cause you to
lose important data!
- new 'create' command for explicit creation
- new 'AutoCreate' trigger to prevent auto-creation on read operations
or both read and write operations
- a few related fixups to the perms command
It creates the repo on the remote side (getting the creator name from
the gl-creator file and sending it across), as well as sending gl-perms
on subsequent connections.
This has only been minimally tested. E.g., complex setups or asymmetric
configs on master and slave, etc. have NOT been tested.
This has also not been tested with redirected pushes.
(but change repo check to allow repoPATT instead of just repoNAME)
This is because there are/will be some situations where access() is
called without those two checks being done (i.e., it is not only from
src/commands/access that it is called).
when running under httpd, $ENV{USER} is not set, so we use a (hopefully
informative) default to print.
Thanks to Thomas Hager (duke at sigsegv dot at) for catching this.
The POST_CREATE trigger is called when
* a user creates a new "wild" repo,
* a user uses the "perms" command, and
* a user uses the "fork" command.
The trigger calls 3 programs (see rc file):
post-compile/update-git-configs
post-compile/update-gitweb-access-list
post-compile/update-git-daemon-access-list
(They are also called by the POST_COMPILE trigger, by the way.)
However, the 3 programs shown are a bit wasteful -- they run through
*all* the repos when really only *one* repo has been affected.
This patch
* passes the repo name to the 3 programs (duh!)
* adds the optimisation to the first of the 3 programs listed above
(the one dealing with 'git config').
For the other two programs (gitweb and git-daemon), you have 3 choices:
* if you don't have too many repos, ignore the problem.
* take out the 2nd and 3rd lines from the POST_CREATE list in the rc
file, so they don't run.
Then run 'gitolite trigger POST_COMPILE' from cron at regular
intervals. (Note that is POST_COMPILE not POST_CREATE!) However,
this means that gitweb and daemon permissions won't be current
immediately after someone adds a new repo or sets perms etc.; they
get updated only on the next cron run.
* patch the programs to add this optimisation (and send me the
patches). The optimisation would check if arg-1 ($1 in shell,
$ARGV[0] in perl) is 'POST_CREATE', and if it is, take the *next*
argument as a repo name that may have changed.
I must have blindly converted from some shell-thinking/shell-code for
these to have slipped through!
(found when doing an audit of all system, exec, ``, qx, and tsh_)
(manually tested, no test script)
the whimsically named "D" command deletes repos, and is the opposite of
the "C" permission that enables the user to create one in the first
place. See the usage message for user info, and look in the comments of
the code itself for admin info.
Sitaram Chamarty
Stephen Palmer
Sebastian Koslowski
Nate Jones
Andreas Stenius
gitolite tester