Greg,
I think your ideas are very good solutions to the problem, but why not
just have an svnserve daemon running on the remote box that waits for
local connections? I agree with all of this; i certainly don't want
permissions to bork my database, i would certainly agree to having only
one user access the database. I already setup an svn user to do just
that :)
But why not use a method that already exists? The only reason i'm using
ssh is that its security is guaranteed by a much larger user base, and
i trust having its port open far more than svnserve -d's port (3970?).
If there was an svnserve daemon that could authenticate a local user
(and not open a remote port!), it would be very handy to many folks.
just my suggestion to what appears to be a big stopping point for a few
people
- paul
On May 26, 2004, at 4:41 PM, Greg Hudson wrote:
>> 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 Wed May 26 23:55:29 2004