On Feb 13, 2004, at 12:59 PM, Garrett Rooney wrote:
> Perry E. Metzger wrote:
>
>> Brian Mathis <bmathis@directedge.com> writes:
>>> The point is that there are already TWO other options that will allow
>>> you to reach the goal you want. 1 is apache, and 2 is svnserve.
>>> Using these requires ZERO code changes to svn. If apache doesn't
>>> meet
>>> your needs, then fine, use svnserve over ssh.
>> How about I drop using svn instead.
>> Actually, I won't do that -- but please bear in mind that ignoring
>> people's needs doesn't encourage people to use a program.
>> So anyway, explain to me exactly how it is that svn+ssh works. What
>> exactly is being invoked over the ssh connection? I was under the
>> impression it WAS svnserve, just being run to stdout instead of over a
>> socket. Why is this, plus setgid or something, a bad idea in any way?
>
> It is svnserve, just run in tunnel mode as the user who ssh'd in. I
> don't know what Brian is talking about. As for running it setgid,
> feel free to give it a shot, I don't know if anyone has tried that
> approach.
As Perry noticed, both use svnserve. Brian's point is that the two
methods that are causing confusion use it in different ways.
1) svn+ssh:// User tunnels to server and as himself runs svnserve *as
himself*. As mentioned many times, this is equivalent to file://
access.
2) Alternative method that uses the same components in a different way:
ssh tunnel with svn:// access via svnserve (which is configured to
allow localhost only connections). User tunnels to server and the
opens a network connection to svnserve which performs the action on the
user's behalf *with the permissions of the svnserve daemon.* This
alternative method achieves the setuid feature that Perry desires.
(2) requires two separate authentications. One sets up the ssh tunnel.
The other is the svnserve CRAM-MD5 authentication. Add non-ssh
encrypted data only travels through the localhost interface, so you
have not opened up any more outward-facing services.
I hope that provides some clarification.
-Travis
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 13 20:24:41 2004