You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Bauer <as...@gatech.edu> on 2009/04/28 14:57:21 UTC
Repository version 1.5+ breaks security model?
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@subversion.tigris.org].
Re: Repository version 1.5+ breaks security model?
Posted by Greg Troxel <gd...@ir.bbn.com>.
I suggest using authz and either https: or svn+ssh: access. If you use
ssh, authz doesn't work by default but there is a setuid tunnel wrapper
in contrib in the sources. It will pass in the original uid as an
argument for authz checking. Then the repo is all owned by the svn
user.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1964902
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Repository version 1.5+ breaks security model?
Posted by David Weintraub <qa...@gmail.com>.
On Tue, Apr 28, 2009 at 11:52 AM, David Bauer <as...@gatech.edu> wrote:
> Is there a reason to not use the file:// protocol? The only thing
> in the FAQ that seems relevant refers to both file:// and ssh+svn://,
> implying any problems are the same in both places.
You don't use the file:// protocol when you have more than one user in
your repository because users have direct access to the repository --
a big no-no. A user could dump the repository, manipulate that dump,
then restore it over the official repository, completely changing your
repository history. And, there is nothing you could do to prevent
this.
Yes, you can have the same issues with ssh+svn://, but it is
recommended that you store your Subversion repository on a system
without user login access. The only way users can manipulate the
repository is via the svnserve process they startup when they connect
to the server. The Subversion manual goes through a whole slew of
configuration tricks to keep users away from direct repository access.
The file:// protocol is for private repositories where I don't want to
go through the bother or effort to setup a server. Personally, I never
use the file:// protocol since I find it easy enough to setup the
svnserve process.
The only reason I use the file:// protocol is when I put the
Subversion repository on my Dropbox <http://getdropbox>. This way, I
have access to my repository from any machine. I can't use svnserve
because I would have multiple svnserve processes on different
computers trying to maintain the same repository.
On Tue, Apr 28, 2009 at 11:52 AM, David Bauer <as...@gatech.edu> wrote:
>> How are your users accessing the Subversion repository. Please tell me
>> they're not using the file:// protocol.
>
> Users use file:// when on the server and ssh+svn (svnserve -t with SSH keys) remotely.
> Is there a reason to not use the file:// protocol? The only thing in the FAQ that seems relevant refers to both file:// and ssh+svn://, implying any problems are the same in both places.
>
>
>> 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.
>
> Will this require the repository to be owned by a dedicated svnuser account?
> I'm guessing that this means for remote access, everybody logs in using SSH to the same user account, and are then differentiated by different SSH keys?
>
>
> David
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1964990
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
>
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1965381
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Repository version 1.5+ breaks security model?
Posted by David Bauer <as...@gatech.edu>.
> How are your users accessing the Subversion repository. Please tell me
> they're not using the file:// protocol.
Users use file:// when on the server and ssh+svn (svnserve -t with SSH keys) remotely.
Is there a reason to not use the file:// protocol? The only thing in the FAQ that seems relevant refers to both file:// and ssh+svn://, implying any problems are the same in both places.
> 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.
Will this require the repository to be owned by a dedicated svnuser account?
I'm guessing that this means for remote access, everybody logs in using SSH to the same user account, and are then differentiated by different SSH keys?
David
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1964990
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Repository version 1.5+ breaks security model?
Posted by David Weintraub <qa...@gmail.com>.
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 <as...@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@subversion.tigris.org].
>
--
David Weintraub
qazwart@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1964721
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].