You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Sebastian Tennant <se...@gmail.com> on 2008/02/26 13:26:55 UTC
Using svnserve securely
Hi list,
How to deploy svnserve securely _and_ provide local read/write access to
a repository at the same time.
_Feedback most welcome_.
For security reasons you should always run publically accessible
services as unprivileged processes, so create an 'svn' system user, make
'svn' the owner of /usr/bin/svnserve and set the setuid bit, like so:
$ ls -ld /usr/bin/svnserve
-rwsr-xr-x 1 svn root 43124 Jun 8 2007 /usr/bin/svnserve
Now, for svnserve to have write access to the repository, the repository
must either be owned by 'svn', or world-writable. Clearly the latter is
undesirable, so make 'svn' the owner of the repository, like so:
$ ls -ld /var/svn-repository
drwxr-xr-x 7 svn root 4096 Aug 11 2007 /var/svn-repository
In terms of EUID and directory permissions svnserve is now securely
deployed, but what about local access?
We can give /usr/bin/svn write access to the repository by doing what we
did to /usr/bin/svnserve and making it 'setuid svn', but then check out
or update operations are only possible in world-writable directories or
directories owned by 'svn' and this time neither solution is desirable.
Also, when a user checks out a batch of new files from the repository
they form part of *her* working copy and should belong to her, not
'svn'.
No, we need to find a way to give /usr/bin/svn write access to the
repository without making it 'setuid svn' and without making the
repository world writable?
Enter *nix groups.
Create an 'svn' system group, make 'svn' the group to which /usr/bin/svn
belongs, and set the setgid bit, like so:
$ ls -ld /usr/bin/svn
-rwxr-sr-x 1 root svn 116988 Jun 8 2007 /usr/bin/svn
Now make the repository writable for members of the group 'svn':
$ ls -ld /var/svn-repository
drwxrwxr-x 7 svn svn 4096 Aug 11 2007 /var/svn-repository
Finally, you also need to make the other /usr/bin/svn* executable files
'setgid svn' (apart from /usr/bin/svnserve).
To summarise:
$ ls -ld /usr/bin/svnserve /usr/bin/svn /var/svn-repository
-rwsr-xr-x 1 svn root 43124 Jun 8 2007 /usr/bin/svnserve
-rwxr-sr-x 1 root svn 116988 Jun 8 2007 /usr/bin/svn
drwxrwxr-x 7 svn svn 4096 Aug 11 2007 /var/svn-repository
Your repository is secure (non-world-writable) whilst granting
write-access to an unprivileged svnserve, and at the same time local
users can still enjoy EUID=UID read/write access.
Sebastian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Using svnserve securely
Posted by Sebastian Tennant <se...@gmail.com>.
Quoth John Peacock <jo...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Using svnserve securely
Posted by John Peacock <jo...@havurah-software.org>.
Miller, Eric wrote:
>> 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.
>
> Except speed. file:// is faster.
Fast or Secure, you can only choose one. file:// vs svn:// on the same
box is not (to the most users anyways) noticeably different in
performance (the svnserve protocol is pretty lightweight).
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Using svnserve securely
Posted by "Miller, Eric" <Er...@amd.com>.
> 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.
Except speed. file:// is faster.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Using svnserve securely
Posted by John Peacock <jo...@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.
>> 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.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Using svnserve securely
Posted by Toby Thain <to...@telegraphics.com.au>.
On 26-Feb-08, at 9:24 AM, Sebastian Tennant wrote:
> Quoth John Peacock <jo...@havurah-software.org>:
>> ...
>
>> 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.
RTFM: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Using svnserve securely
Posted by Sebastian Tennant <se...@gmail.com>.
Quoth John Peacock <jo...@havurah-software.org>:
> Sebastian Tennant wrote:
>> Hi list,
>>
>> How to deploy svnserve securely _and_ provide local read/write access to
>> a repository at the same time.
>>
>> _Feedback most welcome_.
>
> Here's my feedback: don't do this!
Cool.
> Local users don't need read/write access to the repository (using
> file://) and in fact it is a bad idea to give them access.
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?
> 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.
> My 2 cents
Invaluable.
Sebastian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Using svnserve securely
Posted by John Peacock <jo...@havurah-software.org>.
Sebastian Tennant wrote:
> Hi list,
>
> How to deploy svnserve securely _and_ provide local read/write access to
> a repository at the same time.
>
> _Feedback most welcome_.
Here's my feedback: don't do this! Local users don't need read/write
access to the repository (using file://) and in fact it is a bad idea to
give them access. file:// access is ideal for testing, but is not a
robust method for multiuser access; if you are thinking it is faster,
you should consider how long it would take you to recover a corrupt
repository or restore from backup as part of your considerations.
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.
My 2 cents
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org