[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Repository version 1.5+ breaks security model?

From: David Weintraub <qazwart_at_gmail.com>
Date: Tue, 28 Apr 2009 11:19:09 -0400

How are your users accessing the Subversion repository. Please tell me
they're not using the file:// protocol.

You should never muck around with the file permissions on the
Subversion server side. If you aren't using the ssh+svn:// protocol,
you should have a separate Subversion user who owns the repository and
is the only one who can modify the repository. All Subversion users
will talk to a server process that will make the changes in the
repository. The Subversion user will run the server process (whether
svnserve or Apache's httpd process).

To prevent unauthorized users from making changes, you can use a
pre-commit hook to verify that the user has the right permission for
making modification. There is an excellent Python script that you can
use. Preventing people from reading your repository is a bit trickier.
This is done by configuring the server side and differs depending on
what protocol you're using.

By default, Subversion won't allow users to modify revprops which
include their commit comments (svn:log). You need to setup a
pre-revprop-change hook to allow users to modify their own comments.
This is actually pretty simple to do, and Subversion gives you an
example pre-revprop-change hook to use.

On Tue, Apr 28, 2009 at 10:57 AM, David Bauer <astgtciv2009_at_gatech.edu> wrote:
> I recognize that this is a bit out of date, but I just discovered it today.
> I administer a SVN repository for my research group, where we have a large number of users with read/write access.  In order to prevent a user from (accidently or purposely) corrupting the database, the file permissions were set as such:
> drwxr-x--- 2 root svnusers 4096 2007-08-24 09:25 conf
> drwxr-x--- 2 root svnusers 4096 2007-08-24 09:25 dav
> drwxrws--- 5 root svnusers 4096 2009-03-03 19:39 db
> -rw-r----- 1 root svnusers    2 2007-08-24 09:25 format
> drwxr-x--- 2 root svnusers 4096 2007-09-27 15:01 hooks
> drwxr-x--- 2 root svnusers 4096 2007-08-24 09:25 locks
> -rw-r----- 1 root svnusers  229 2007-08-24 09:25 README.txt
> On the db directory:
> -rw-rw---- 1 david svnusers    9 2009-03-03 19:39 current
> -rw-r----- 1 root  svnusers    2 2007-08-24 09:25 format
> -rw-r----- 1 root  svnusers    5 2007-08-24 09:25 fs-type
> drwxrws--T 2 root  svnusers 4096 2009-03-03 19:39 revprops
> drwxrws--T 2 root  svnusers 4096 2009-03-03 19:39 revs
> drwsrws--T 2 root  svnusers 4096 2009-03-03 19:39 transactions
> -rw-r----- 1 root  svnusers   37 2007-08-24 09:37 uuid
> -rw-rw---- 1 root  svnusers    0 2007-08-24 09:25 write-lock
> The contents in the revs and revprops directories look like:
> -rw-r----- 1 david  svnusers  3500 2009-03-03 19:39 274
> So, a user can only change their own commits.
> (svnadmin verify and a backup of the repository are done by cron jobs, so if a user changes a commit that came before another user's commit, the non-matching checksum would be flagged.)
> Now, with repository version 1.5+ (fsfs version 5, db version 3), I can't find any way to do the same thing.  The first error I encountered was creating txn-current.tmp.  Then, it tries to move txn-current.tmp over txn-current.  I can't see any way to do that without giving users the ability to overwrite every file in the directory.  A similar problem occurs with current.tmp -> current.
> Is this type of security model not supported any more, or is there a way to make it work still?
> David Bauer
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1964429
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].

David Weintraub
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-28 17:21:04 CEST

This is an archived mail posted to the Subversion Users mailing list.