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

Re: Somewhat corrupted repository: Berkeley DB Permissions errors on SVN 1.0.2

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-05-26 22:41:58 CEST

> The current permissions and access system is very confusing to those
> who are developers, not unix sysadmin gurus. As it is, svn+ssh does
> not work correctly out of the box. Why does it work the way it
> currently does (that is, designed to ignore that it needs some type
> of umask intervention), and is there change in the wind? Do I have
> to do the somewhat dodgy umask shuffle, or is there another way?

Lots and lots of people run into this problem, and yes, it sucks.
There are three changes in the wind:

  * In svn 1.1, there will be an svnserve --tunnel-user option, which
    you can use in combination with the "command" directive in the
    authorized_keys file to set up svn+ssh so that you have one system
    account with many users, each user having a distinct key.

  * In svn 1.1, there will be an alternate FS back end (FSFS) which
    does not use BDB and does not have the umask requirement. (It
    still has the requirement to set the db directories g+s if you're
    using group access permissions, so things may quite not work "out
    of the box." Not certain if there's anything we can legitimately
    do anything about that. Anyway, it's a lot closer.)

  * Some future version of BDB is supposedly going to have a flag we
    can set so that new logfiles are chmodded after creation. We have
    no idea when that will happen, though.

We have considered stopgap fixes, like adding a umask directive to
svnserve.conf, but they are half-measures and come with a lot of
associated pain (umask isn't portable and you can't have separate
umasks for each repository if the server is running in threaded mode),
so we haven't implemented them.

We've also considered adding better diagnostics (checking to make sure
you have write access to the DB files before trying to open the
database, and giving a better error message than "your DB is corrupt,
run recovery"), and I think approved the idea, but I believe failed to
implement them out of lameness.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 28 17:24:31 2004

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

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