-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Coppit wrote:
| My systems staff doesn't want to change /usr/bin/svn, so I have put my
| umask-svn wrapper in a different path. The problem is getting all my
| developers to make sure that path is in their PATH. If they don't run the
| wrapped version, the database will get corrupted.
|
| Here's a pre-commit script that will double check that svn+ssh is getting
| the svn wrapper.
|
| #!/usr/bin/perl
|
| use strict;
|
| my $repository_machine = 'ENTER YOUR REPOSITORY MACHINE HERE';
| my $wrapped_svn_path = 'ENTER THE PATH TO YOUR SVN WRAPPER HERE';
|
| my $user = `whoami`;
| chomp $user;
|
| my $svn = `ssh $user\@$repository_machine which svn`;
| chomp $svn;
|
| if ($svn ne "$wrapped_svn_path/svn")
| {
| die<<EOF;
|
|
=============================================================================
|
| You are blocked from using the repository until you set your PATH
| environment
| so that $wrapped_svn_path appears first, so that you will run the
wrapped
| version of svn instead of the system one.
|
| If we let you continue, you could corrupt the database! Here's the svn
| that
| you ran: "$svn"
|
|
=============================================================================
|
| EOF
| }
|
| exit 0;
|
| I hope that helps anyone else in the same boat as me.
Unfortunately, that won't work. The pre-commit wrapper is run on the
server, not the client. While you could trace the parent processes to
find out which svn is being used, it would be too late - by the time the
pre-commit hook is run the database has already been touched. You could
add a start-commit hook to check the umask, but that too might be too
late. Additionally, openssh at least has a nasty habit of ignoring
user-set environment variables for security reasons. Instead, it uses
some system-wide defaults.
One solution is to use fsfs - with fsfs the umask doesn't matter.
Failing that, run svnserve or apache2 from one user account, which also
renders umask issues irrelevant. If none of these are feasable, you can
reduce the chance of problems on a repository with low load with the
following line in all of the hook scripts:
chmod -R g+rwX $PATH_TO_REPOS 2>/dev/null || true
This will reset the permissions of the repository to be correct.
However, if the repository is accessed between when the log file is
created and the script is run, the repository will still wedge.
Ultimately, the best solution is to remind the systems staff that their
job is to help you do your job, not the other way around. If they refuse
to set the path globally or modify /usr/bin/svn and /usr/bin/svnserve,
and fsfs is not an option, subversion simply will not work properly in
your configuration.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCBcWC+hz2VlChukwRAkYfAKCZuOCAI1EyPG9Ezud9I8uuK0NVqwCferUs
jFHjfZ6sqJpzmOWZBW/kQbQ=
=WeCS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Feb 6 13:13:16 2005