>>>>> "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
Jarod> svnserve. Oh yeah (sorry, still very green to Subversion). But
Jarod> the passwords sit in a file unencrypted. Icky. And I have to
Jarod> maintain multiple user/password databases, rather than using
Jarod> the 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).
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.)
Terry
---------------------------------------------------------------------
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:27:57 2004