Quoth John Peacock <john.peacock_at_havurah-software.org>:
> Sebastian Tennant wrote:
>> Are you saying that /usr/bin/svn commands, issued locally from within a
>> working copy ('svn ci -m "test" test.file' for example) effectively have
>> write permission to the repository regardless of the repository
>> directory's file permissions?
>
> If the working copy was checked out using file::///path/to/repos
> (which is what you were essentially describing), then yes, the clients
> have to have write access to the repos. Such users could then type
> rm -rf' and delete the repository.
Eeep!
>>> Just use a server process that owns the repository files exclusively
>>> and have the local users access the repo exactly like the remote users
>>> - via the server process. Whether you use svnserve or Apache, it is
>>> much more robust and secure to have the repository unavailable via
>>> file:// completely.
>>
>> I did consider this but I couldn't think how to actually do it in
>> practice. Some (newbie level) examples of how this is achieved would be
>> much appreciated.
> Have the local users do this:
>
> $ svn co svn://servername/repos/project/files
>
> instead of this:
>
> $ svn co file:///path/to/repos/project/files
>
> The remote users will use exactly the same command as the local.
> There is no benefit to giving local users access to the repository
> files themselves.
Of course!
And sufficiently restrictive permissions on the repository directory
force users to use this method.
Setting up a single _secure_ repository only accessible by svn:// is an
option that could easily be presented and handled by the
pre-installation scripts of packaged versions of Subversion at install
time. I'm suprised it isn't.
Many thanks.
Sebastian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-26 18:40:14 CET