On Tue, Jul 19, 2011 at 12:16 PM, Bob Archer <bob.arc...@amsi.com> wrote: >> The most obvious authorization scheme is that of the host server; >> if >> there is a user named "andy" on that server with a password >> "jackel" >> then I would like to simply be able to talk to the subversion >> server as >> user named "andy" password "jackel". This is how ssh and sftp work. >> But >> apparently subversion can't handle that. True? > > I would say FALSE. > > BOb
It's feasible, but problematic. The solution involves giving "andy" a valid account on that machine, one with a local or network password, because the "andy" account needs to be able to run the "svnserve" program. And doing this leads to risks of exposing the rest of the system to all your Subversion users. Also, group ownership to a shared repository needs to be carefully managed, and it puts the repository at risk of malcious users simply logging in and deleting bits from the Subversoin database. The only well supported solution to this, so far, is to use SSH keys for a shared account, and to use those keys to use a forced "command" for that shared account, a "command" that enforces the user's name for that particular svnserve instance. I've previously tried, myself, to help set up a restricted shell for just such access, starting with the "rssh" tool, but didn't get very far. That would be a significant security improvement, and help protect the rest of the OS from unauthorized access with valid Subversion logins with Kerberized or other account access, rather than SSH keys.
