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

RE: Access right question

From: Sander Striker <striker_at_apache.org>
Date: 2003-06-20 16:45:44 CEST

> From: Michael Schmitt [mailto:schmitt@TI.Uni-Trier.DE]
> Sent: Friday, June 20, 2003 11:18 AM

> Dear SVN developers,
>
> I have a question concerning the access rights of an svn repository.
> When using the "ra_local" method (svn version 0.23), you face the
> problem that whenever a user commits some changes, Berkeley DB stores
> the transaction in a log file ("log.000000XXXX"). From time to time, a
> new log file is created. Of course, its owner is the same as the user
> that has commited the changes and, of course, the access rights of the
> files are those of the user.
>
> Now, if the user has a strict umask (0077), other users will not be able
> to access the repository in the following and svn asks you to recover
> the data base if you try to nevertheless.
>
> I tried to solve this access problem by adding the following line in
> hook "post-commit" (note: we trust all users in our network)
>
> find ${REPOS}/db -user ${UID} -exec chmod ugo+rw {} \;
>
> While this seems to work well in most cases, I noticed that Berkeley DB
> adds log information even in case of a "checkout"! (I can't see any
> reason why this is so).

Because a checkout causes a _write_.

> Unfortunately, I do not know how to handle this
> situation because there is no corresponding hook available.
>
> How do other people handle the access rights when using "ra_local"?

Use a simple wrapper:

#!/bin/sh
umask 002
/path/to/real/svn "$@"

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 20 16:46:36 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.