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

RE: Re: bad access methods (was: 100% repeatable repo wedging)

From: Jarod Wilson <jarod_at_voicebox.com>
Date: 2004-03-04 22:37:40 CET

> -----Original Message-----
> From: terry@eatoni.com [mailto:terry@eatoni.com]
> >>>>> "Jarod" == Jarod Wilson <jarod@voicebox.com> writes:
> Jarod> Not particularly useful in my particular instance, since I'd
> Jarod> rather have unique logins. Oh! Wait! I'm now remembering that
> Jarod> svnserve.conf file... I *can* have unique logins with
> svnserve.
> Jarod> Oh yeah (sorry, still very green to Subversion). But the
> Jarod> passwords sit in a file unencrypted. Icky. And I have to
> Jarod> maintain multiple user/password databases, rather than
> using the
> Jarod> system one.
> You don't need to use svn's concept of a user/password etc.
> It's especially easy to set up and play with if the people
> you want to have accessing your repos already are accessing
> CVS on the same machine.
> You make them come in via svn+ssh and then svnserve -t is
> invoked for them on the repos machine. No need for any access
> control above and beyond ssh (though of course you can have
> that too if you want).

I think you missed the beginning of this thread. That's exactly what I'm
doing. ;-)

> And this last remark brings us back to the original problem:
> svnserve -t being run by many user ids and causing problems
> with permissions.
> The chmod g+s on the repos directory should certainly be done
> for those on a suitable flavor on UNIX.
> Another possibility is simply making svnserve owned by a
> non-root user and setting the setuid bit. I'm sure that must
> have been tried and it's likely no less secure than anything
> else - after all, the svnserve process has to run under
> _some_ user id. (This approach may confuse svn as to who the
> actual user doing the svn operation is though, depending on
> how that information is obtained.)

Personally, I was ecstatic when first delving into Subverion and I found
out about the svn+ssh method. Like someone else said, you don't have to
open anymore ports on the firewall for external developer access, you
can use the system user database and everything runs over an encrypted
channel. Perfect for my situation, once I pulled my head out and got the
repo umask set right.

Jarod C. Wilson, RHCE
System Administrator
VoiceBox Technologies
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 4 22:36:38 2004

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