seanc@dimensionalrift.com wrote:
>>seanc@dimensionalrift.com wrote:
>>
>>
>>
>>>I would be willing to go with the ra_svn approach but it doesnt seem
>>>possible to secure it in a meaningful manner for a multi-user
>>>configuration. Perhaps if svnserve were to run exclusively on 127.0.0.1
>>>and a proxy program (say, svnproxy) could be executed via rsh or plink
>>>
>>>
>>>from my clients I could at least secure it in the same way as CVS.
>>
>>
>>uh, you can already tunnel ra_svn over ssh, just as one normally does
>>with CVS. there's no reason to run svnserve in daemon mode if you don't
>>want to.
>>
>>-garrett
>>
>>
>>
>>
>
>The database has never let me do that. I've had to run db4.1_recover any
>time the user changes on the database. I.e:
>
>As root I create /usr/local/svn and chown it to root:svnusers, and chmod
>it g+s
>As user 'foo' I run svnadmin create testdb, from /usr/local/svn
>As user 'foo' I can access the database
>Access with any other user, Permission denied: Berkeley DB error
>while opening environment for filesystem /usr/local/svn/testdb until I
>run db4.1_recover on the database as that user. chown'ing the directory
>to that user fully does not help. I have to run db recover. This
>included getting the www-data user to work so that apache could access the
>database.
>
that's a separate problem. when you run svnserve you need to be sure
that your umask is set correctly so that files you create can be
read/written by all the users who need to access the database. this
generally means making sure all the accounts are members of the same
group and making the repository owned by that group. in you don't want
to have your users set their umask to make things group writable by
default, you can work around it by using a wrapper script instead of
svnserve which sets the umask correctly and then calls svnserve. there
are several examples of how to do this in the archives, i don't have one
handy at the moment.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 25 21:26:41 2003