Please remember to Reply All so your reply goes not just to me but to
the whole group, where someone else may be able to provide another
perspective.
On Sep 3, 2008, at 9:27 AM, Anton Pervukhin wrote:
> Ryan Schmidt wrote:
>
>> And disabling ra_local in your client won't provide any increased
>> security, since anyone could bring in another client that does
>> have ra_local. If you're trying to prevent people from accessing a
>> repository using ra_local, then ensure that those users do not
>> have read/write access to the repository files on the server. Only
>> your svnserve or apache user should have read/write access, thus
>> ensuring all access occurs though those processes.
>
> that was exactly the point. in our academic environment we wanted
> to restrict access to some users to certain paths in the
> repository. That was done for accesses via https and svn+ssh by
> just supplying an AuthzSVNAccessFile with permissions on directory
> bases. This had an advantage of not touching unix accounts. Now as
> it looks like this is not possible to close ra_local, we have to:
> 1. create a new repository for stuff to be secured.
> 2. create a new group for a new repository
> 3. put users that have security rights to this group.
>
> As you see, this is a bit more work ;-)
Why make a new repository? Why not just secure the repository you
have? Just change its user and group to the apache user, and change
the permissions so that only the apache user can read and write to
it. All access to the repository should be through apache. No access
to the repository should be permitted through the file protocol.
Anyone who has file-protocol access to a repository can also read or
change your hook scripts or delete the entire repository,
accidentally or intentionally.
>>> I have searched this mailing list and googled a bit, have found a
>>> bit old thread: http://svn.haxx.se/dev/archive-2004-02/0796.shtml
>>> where it is said that for disabling ra_local one should build
>>> subversion without berkeley db support, i.e. with configure
>>> option: --without-berkeley-db
>>
>> Well, that message is from February 2004, when BerkeleyDB was the
>> only repository storage format. In order for Subversion to read a
>> repository from disk, it needed to use BDB to do so; I suspect
>> that if BDB was not available, it simply didn't build the apache
>> server module, svnserve server binary, or the ra_local client
>> repository access method, because there would be no way for them
>> to work.
>>
>> But when Subversion 1.1 was released in September 2004, it gained
>> a second repository storage format, FSFS, which has no
>> dependencies. Thus it is now always possible to build these
>> features (though without BDB, they can only access FSFS-type
>> repositories and not BDB-type repositories).
>>
>> http://subversion.tigris.org/svn_1.1_releasenotes.html
>>
>>> here is my configure script (on Solaris 5.10):
>>>
>>> /configure --prefix=/vol/software/subversion-1.4.3 --with-swig=/
>>> vol/software/swig-1.3.29 --with-jdk=/usr/java --with-ssl --
>>> enable-shared=no --with-neon=/vol/software/neon-0.25.5 --with-
>>> apr=/vol/software/source/src/subversion-1.4.3/apr --with-apr-
>>> util=/vol/software/source/src/subversion-1.4.3/apr-util --without-
>>> berkeley-db
>>>
>>> apr and apr-util I'm getting from dependencies package. neon,
>>> version 0.25.5 has been installed separately.
>>>
>>> interesting enough configure script even logs warning:
>>>
>>> configure: WARNING: we have configured without BDB filesystem
>>> support
>>>
>>> You don't seem to have Berkeley DB version 4.0.14 or newer
>>> installed and linked to APR-UTIL. We have created Makefiles which
>>> will build without the Berkeley DB back-end; your repositories will
>>> use FSFS as the default back-end. You can find the latest
>>> version of
>>> Berkeley DB here:
>>> http://www.sleepycat.com/download/index.shtml
>>>
>>> but still after...
>>>
>>> make
>>> make install
>>>
>>> svn --version gives
>>>
>>> svn, version 1.4.3 (r23084)
>>> compiled Sep 1 2008, 11:35:34
>>>
>>> Copyright (C) 2000-2006 CollabNet.
>>> Subversion is open source software, see http://
>>> subversion.tigris.org/
>>> This product includes software developed by CollabNet (http://
>>> www.Collab.Net/).
>>>
>>> The following repository access (RA) modules are available:
>>>
>>> * ra_dav : Module for accessing a repository via WebDAV (DeltaV)
>>> protocol.
>>> - handles 'http' scheme
>>> - handles 'https' scheme
>>> * ra_svn : Module for accessing a repository using the svn
>>> network protocol.
>>> - handles 'svn' scheme
>>> * ra_local : Module for accessing a repository on local disk.
>>> - handles 'file' scheme
>>>
>>> I have already tried different scenarios: apr and apr-util built
>>> separately, removed installation of berkeley db from the
>>> PATH...and still no success.
>>>
>>> So basically I can't get a point where it gets the link to
>>> berkeley db (may be from some other library: swig, apr, apr-util,
>>> neon???) and why it builds it even with the configure option --
>>> without-berkeley-db.
>>
>> It's not linking with BerkeleyDB. Your binary is built without
>> BerkeleyDB support. You asked for that by using the "--without-
>> berkeley-db" configure option, and the configure script confirmed
>> that for you by saying "we have configured without BDB filesystem
>> support". So your Subversion binaries cannot access BDB-type
>> repositories locally. They can access FSFS-type repositories
>> locally, and can access any type of repository that is served by a
>> server running an svnserve or mod_dav_svn built with BDB support.
>
> thank you for clarifying this. This hasn't been clear to me based
> on the above output from svn --version
> but as I ran svnadmin --version I realized that BerkeleyDB support
> is indeed off. Why then commands like
>
> svn ls file:///vol/svn
>
> still work? Because this repository is fsfs-type? How could one
> find out of which type is the repository?
Probably. FSFS is the default repository type for any repository
created with Subversion 1.2.0 or later.
To find out what kind of repository you have, look at the contents of
the file fs-type in the db directory in your repository directory.
>> The only thing I can think of would be to remove the files
>> libsvn_ra_local-1.* from ${prefix}/lib after installation is done.
>
> I tried this as well, but again
>
> svn ls file:///vol/svn
>
> did function as before. Magical robustness ;-)
Then I think you must have another copy of the ra_local library
somewhere.
On Mac OS X 10.5, which comes with Subversion 1.4, I installed
Subversion 1.5 using MacPorts. If I delete its ra_local files, I can
no longer do anything with repositories with the file protocol. Using
the Subversion 1.5 binary, it's finding the Subversion 1.4 ra_local
library installed by Apple as part of Mac OS X, which isn't
compatible, and I get this error:
$ svnadmin create repo
$ svn info file://`pwd`/repo
svn: Mismatched RA version for 'file': found 1.5.2, expected 1.4.4
$
I also installed Subversion 1.5 with MacPorts on Mac OS X 10.4, which
does not come with Subversion. If I delete its ra_local files and try
to access a repository with the file protocol, svn crashes saying it
cannot load the ra_local dynamic library.
$ svnadmin create repo
$ svn info file://`pwd`/repo
dyld: Library not loaded: /mp/lib/libsvn_ra_local-1.0.dylib
Referenced from: /mp/bin/svn
Reason: image not found
Trace/BPT trap
$
So while the error message isn't good, deleting the ra_local files
should indeed prevent people from using the file protocol (*with that
client*; again, anyone could install or compile a different client
that does have ra_local support, therefore removing the ra_local
files from your client cannot be considered a method of securing your
repository). If you want to go this route, you could improve the
error message by making a wrapper script around the svn binary, and
your wrapper could notice any URLs using the file protocol and print
a better error message.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-04 08:38:38 CEST