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

Re: svnserve -r not working?

From: Dimitri Papadopoulos-Orfanos <papadopo_at_shfj.cea.fr>
Date: 2004-04-28 14:56:36 CEST

Hi,

Thank you for your prompt answer.

> As I believe I noted in the message you replied to, there are some
> changes in the trunk which will make this better someday. In essence,
> the changes permit all svn+ssh:// access via a single user account, but
> in a way that maintains the AUTHOR field (you can do it now but all
> commits would be from the same user).

In my case it's not matter of limiting the number of accounts, rather
it's a matter of limiting what each of these accounts can do.

>> Since in the Subversion case SSH has to spawn its own svnserve
>> instance, is there any other way to constrain Subversion users to run
>> svnserve and nothing else? I guess one should use a constrained shell,
>> but I have no experience with that. Does anyone have some
>> recipe/shell/script to share?
>
>
> If you don't mind setting them up as individual users, you can actually
> force the ssh connection to execute an application when connecting (it's
> part of the authorized_keys stanza). It's actually part of how the

That's much better, but as far as I can understand that works only when
using public key authentication. Using password authentication bypasses
authorized_keys.

> patch I mention above works. See this thread for:
>
> http://www.contactor.se/~dast/svn/archive-2004-02/0220.shtml
>
> especially the first message cited above which shows the use of
> 'command=' in the authorized_keys file.

I'd rather constrain the shell than constraining each authentication
method separately.

--
Dimitri
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 28 14:57:11 2004

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.