You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Michael Schmitt <sc...@TI.Uni-Trier.DE> on 2003/06/20 09:17:49 UTC

Access right question

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). 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"? If 
there is a nicer solution than mine, a short description should go into 
the 'SVN Book'. I guess many people have the same problem and would be 
grateful for some hints.

Kind regards,

Michael



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Access right question

Posted by Branden Robinson <br...@deadbeast.net>.
On Wed, Jun 25, 2003 at 05:18:36AM -0400, Greg Hudson wrote:
> Uh, backwards.  "$@" is how you pass an unmolested argument list. 
> (Except with some rather old Bourne shell implementations, where you
> have to use ${1+"$@"} to avoid turning an empty argument list into an
> argument list with one empty word.  But nobody worries about that any
> more.)
> 
> > % ./foosh one two "three four"
> > one two three four
> > one
> > two
> > three four
> 
> You'll note that "$*" smashed the four arguments into one word, while
> "$@" kept them as three words.

Er, yup.  That'll teach me to send mail in the small hours.

Oh well.  My code didn't lie even if my words did.  :)

Thanks for the clue application.  :)

-- 
G. Branden Robinson            |      Optimists believe we live in the
Free Software Developer        |      best of all possible worlds.
branden@deadbeast.net          |      Pessimists are afraid the optimists
http://deadbeast.net/~branden/ |      are right about that.

Re: Access right question

Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2003-06-25 at 04:49, Branden Robinson wrote:
> 2) I personally don't use "$@" when I am not parsing the argument list.
>    That is because "$@" actually changes the internal quoting of the arg
>    list and $* does not.

Uh, backwards.  "$@" is how you pass an unmolested argument list. 
(Except with some rather old Bourne shell implementations, where you
have to use ${1+"$@"} to avoid turning an empty argument list into an
argument list with one empty word.  But nobody worries about that any
more.)

> % ./foosh one two "three four"
> one two three four
> one
> two
> three four

You'll note that "$*" smashed the four arguments into one word, while
"$@" kept them as three words.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Access right question

Posted by Branden Robinson <br...@deadbeast.net>.
On Fri, Jun 20, 2003 at 04:45:44PM +0200, Sander Striker wrote:
> Use a simple wrapper:
> 
> #!/bin/sh
> umask 002
> /path/to/real/svn "$@"

Picking some shell nits here:

1) I'd prefix that last line with "exec" and save a slot in the process
   table.
2) I personally don't use "$@" when I am not parsing the argument list.
   That is because "$@" actually changes the internal quoting of the arg
   list and $* does not.

Consider the following:

% cat ./foosh
#!/bin/sh

for F in "$*"; do
        echo "$F"
done

for F in "$@"; do
        echo "$F"
done
% ./foosh one two "three four"
one two three four
one
two
three four

Because our wrapper is not itself attempting to make sense of the
argument list, it should pass on the user's instructions about what the
arguments are to svn completely unmolested.

This might be important if people are keeping filenames with embedded
spaces or shell metacharacters under version control with Subversion.

-- 
G. Branden Robinson            |       It just seems to me that you are
Free Software Developer        |       willfully entering an arse-kicking
branden@deadbeast.net          |       contest with a monstrous entity
http://deadbeast.net/~branden/ |       that has sixteen legs and no arse.

Re: Access right question

Posted by Ben Collins-Sussman <su...@collab.net>.
Sander Roobol <ph...@wanadoo.nl> writes:

> On Fri, Jun 20, 2003 at 10:04:18AM -0500, Ben Collins-Sussman wrote:
> > "Sander Striker" <st...@apache.org> writes:
> > 
> > > > 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_.
> > 
> > This has become a FAQ as well.  I should write it up.
> > 
> > Everybody listen:  checkouts and updates are produced by having the
> > server compare two trees.  One tree is the HEAD revision (usually),
> > and the other is a temporary transaction-tree -- thus the need for
> > write access.
> 
> Just curious, does this also happen with svn switch?

Yes.  'svn switch' and 'svn update' are exactly the same thing, under
the hood.  For UI sanity, we created two separate subcommands.  'svn
st -u' is also an update, it just doesn't apply the changes.  And many
cases of 'svn diff', obviously, cause the server to compare trees as
well.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Access right question

Posted by Sander Roobol <ph...@wanadoo.nl>.
On Fri, Jun 20, 2003 at 10:04:18AM -0500, Ben Collins-Sussman wrote:
> "Sander Striker" <st...@apache.org> writes:
> 
> > > 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_.
> 
> This has become a FAQ as well.  I should write it up.
> 
> Everybody listen:  checkouts and updates are produced by having the
> server compare two trees.  One tree is the HEAD revision (usually),
> and the other is a temporary transaction-tree -- thus the need for
> write access.

Just curious, does this also happen with svn switch?

Sander

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Access right question

Posted by Ben Collins-Sussman <su...@collab.net>.
"Sander Striker" <st...@apache.org> writes:

> > 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_.

This has become a FAQ as well.  I should write it up.

Everybody listen:  checkouts and updates are produced by having the
server compare two trees.  One tree is the HEAD revision (usually),
and the other is a temporary transaction-tree -- thus the need for
write access.

> > How do other people handle the access rights when using "ra_local"?
> 
> Use a simple wrapper:
> 
> #!/bin/sh
> umask 002
> /path/to/real/svn "$@"

And this is described in the book as well:

   http://svnbook.red-bean.com/html-chunk/ch05s05.html


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: Access right question

Posted by Sander Striker <st...@apache.org>.
> 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