Our wonderful anti-virus/spam system decided to remove the batch file
from the outgoing message, so here it is in-line. You need to save this
to a file called pre-commit.bat
REM Make sure that the log message contains some text.
SET SVNLOOK="c:\program files\svn-win32-1.1.2\bin\svnlook"
REM Check that the author of this commit has the rights to perform
REM the commit on the files and directories being modified.
REM Cause PERL on Win32 can't fork properly, need to get some inputs at
%SVNLOOK% author -t %TXN% %REPOS% > G:\Auth%TXN%.txt 2>&1
%SVNLOOK% dirs-changed -t %TXN% %REPOS% > G:\Dirs%TXN%.txt 2>&1
%SVNLOOK% changed -t %TXN% %REPOS% > G:\Chng%TXN%.txt 2>&1
G:\SVNSource\Admin\Scripts\commit-access-control.pl %REPOS% %TXN%
IF ERRORLEVEL 1 GOTO BADEXIT_DEL
REM All checks passed, so allow the commit.
GOTO SCRIPT_FAILED 2> NUL
From: Butlin, Jason (UK - Epsom)
Sent: 01 February 2005 09:43
To: Benjamin C. Allfree; email@example.com
Subject: RE: Howto: user-level permissions on Windows?
It depends what sort of access restrictions you want. I don't
believe you can limit the read access on a folder by folder basis, but
you can limit the ability to commit to certain folders.
What you need to do is create a pre-commit hook for the
repository in question. This will then check the user performing the
commit, check the files being committed, and only allow the process to
continue if the user has access to all the relevant folders. There is
mention of this in the documentation, and an example Perl script that
does exactly what you want in the SVN repository.
Unfortunately, all the examples are based on Unix/Linux, which
can actually run Perl properly - unlike Windows. So for the benefit of
and Windows users out there....
Firstly, you need to install a Perl interpreter on the SVN
server machine, such as http://www.activestate.com/Products/ActivePerl/
You then need to place the attached batch file into the hook
sub-directory of the repository to be controlled, changing the
references to drives and the script location accordingly. You'll notice
that a number of files get created to the root of G: in my case. This is
necessary because Perl on Windows cannot fork the look process
correctly. So I got round the problem getting the batch file to create
these temporary files, which the Perl script can then read.
You then need to place the attached Perl script into the
directly that matches the call from the batch file. This is basically
the same script provided as an example with the SVN source code, but
with changes to read the temporary file and work under Windows
Last step. You now need to create the file that holds the
security information. Unfortunately, I've removed all the comments from
my file, but it's fairly straight forward to work out the format. Create
a file in the root of the repository to be protected called
commit-access-control.cfg. In this file, you can create a number of ini
sections with the following format
match = sed_style_matching_string
users = user1
users = user2
access = read-write or read-only
Here's a few entries from my cfg file
match = .*
access = read-only
[Give administrators global access]
match = .*
users = jbutlin
access = read-write
[Allow writing to the Installation Trunk]
match = ^Installation/Trunk
access = read-write
Hope that helps
From: Benjamin C. Allfree [mailto:firstname.lastname@example.org]
Sent: 31 January 2005 03:41
Subject: Howto: user-level permissions on Windows?
I see that Subversion's stand-alone server allows for
repository-level permissions, but is there a way to do user-level
permissions on Windows without running Apache? I want to restrict access
to certain project folders within the same repository.
If you have received this e-mail in error or wish to read our
e-mail disclaimer statement and monitoring policy, please refer to the
statement below or contact the sender.
This communication is from Deloitte & Touche LLP. Deloitte &
Touche LLP is a limited liability partnership registered in England and
Wales with registered number OC303675. A list of members' names is
available for inspection at Stonecutter Court, 1 Stonecutter Street,
London EC4A 4TR, United Kingdom, the firm's principal place of business
and registered office. Deloitte & Touche LLP is authorised and
regulated by the Financial Services Authority.
This communication and any attachments contain information which
is confidential and may also be privileged. It is for the exclusive
use of the intended recipient(s). If you are not the intended
recipient(s) please note that any form of disclosure, distribution,
copying or use of this communication or the information in it or in any
attachments is strictly prohibited and may be unlawful. If you have
received this communication in error, please return it with the title
"received in error" to IT.SECURITY.UK@deloitte.co.uk
<mailto:IT.SECURITY.UK@deloitte.co.uk> then delete the email and
destroy any copies of it.
E-mail communications cannot be guaranteed to be secure or error
free, as information could be intercepted, corrupted, amended, lost,
destroyed, arrive late or incomplete, or contain viruses. We do not
accept liability for any such matters or their consequences. Anyone who
communicates with us by e-mail is taken to accept the risks in doing so.
When addressed to our clients, any opinions or advice contained
in this e-mail and any attachments are subject to the terms and
conditions expressed in the governing Deloitte & Touche LLP client
Opinions, conclusions and other information in this e-mail and
any attachments which do not relate to the official business of the firm
are neither given nor endorsed by it.
Received on Tue Feb 1 10:59:25 2005