On Mon, Jul 26, 2010 at 5:55 AM, Ulf Seltmann <seltmann_at_digitalzone.de> wrote:
> Am 24.07.2010 04:46, schrieb Nico Kadel-Garcia:
>>
>> On Fri, Jul 23, 2010 at 6:25 AM, Ulf Seltmann<seltmann_at_digitalzone.de>
>> wrote:
>>>
>>> Hello all,
>>>
>>> i'm hav a multihost environment and i want to provide svn access for
>>> arbitrary customers via dav_svn. is there a solution to have the
>>> svn-directories of the users only available to the unix-users of the
>>> customer instead to make them writable to the apache user (which
>>> mod_dav_svn
>>> is using due to the fact that its an apache-module?
>>
>> Yes. Switch *EVERYONE* to ssh+svn for protected access,
>
> No. thats not acceptable, because every user that needs access tho the svn
> needs an pam-, respektively unix-account. the administrative expense would
> be to high. i want my customers to add/remove the svn-users via
> .htpasswd/webfrontend
What? No-no-no. This is a common misconception about the use of
ssh+svn. The standard configuration for ssh+svn is to set up a single
"svnuser" account that owns the repository, and everyone uses svn+ssh
pointing to that username, for example:
ssh+svn://svnuser@svnhost/svnrepo/
The svnuser has its password locked and unusable, and it's shell set
to /sbin/nologin. The SSH clients have their public SSH keys set,
ideally public keys used for this alone though that's hard to enforce,
and the keys are used for the svnuser's "authorized_keys" file to run
the svnserve command with the "--user" option. This is the typical
syntax, from the Subversion book, with "TYPE1 KEY1" being copied from
the SSH key for "harry".
command="svnserve -t
--tunnel-user=harry",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty
TYPE1 KEY1 harry_at_example.com
>> because https and http and svn access all still have the issue of the UNIX
>> or Linux
>> clients saving passwords in cleartext, with no way for the server to
>> prevent it. Or insist that UNIX users also use https: there is no
>> reasonable excuse for providing direct write access to the repository
>> as other users.
>
> only https is allowed for svn
That's fine. The problem still stands. Afer all the work of using
https, and keeping your passwords encryptsed on the wire, the UNIX and
Linux clients still keep passwords in the clear.
>>> maybe it is possible to use cgi-access to svnserve to use suexec?
>>
>> It gets tricky. ssh+svn allows you to channel all access to go through
>> a particular 'uid' that has the correct permissions set to be able to
>> write to the repository. It's possible to set the repository
>> permissions with group permissions, and directory permissions of 4775,
>
> 4770! no reason to give all read access
Fair enough. Tastes vary.
>> to have a shared group of which the "apache" user is a member. But I
>> prefer, very strongly, to force the Subversion repository to be owned
>> by a single user for management and permissions control.
>
> Yes me too. But as i mentioned above: its a no go. i will not add an
> unix-account for every silly user my customers want to have access to their
> svn. although i don't want to give writepermissions to apache-group 'cause
> its a potential securityrisk i cant estimate. i have to add the unix-user to
> that group too and so the user has theoretically access th all svn
> directories set up like this.
Fortunately, you don't have to.
Received on 2010-07-26 13:28:40 CEST