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

Re: Can't build subversion without ra_local support ('file' scheme)

From: Matt imMute Sickler <immute_at_msk4.ath.cx>
Date: Fri, 05 Sep 2008 13:01:27 -0500

Anton Pervukhin wrote:
>
>>> 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.
> in fact, we have setup the repository it this way: repository belongs to
> apache user and group svn, apache user and svn have full access (except
> svn users don't allow to modify conf, hook etc files), others - none.
> But what to do if we want to restrict an access to certain paths in
> repository to some users who belong to svn group? Imagine, we have
> students working in our department, they belong to svn group, since we
> want them to access repository as well and we have a path in the
> repository where the exercises, exams to our lectures, including
> solutions are stored. Obviously, we would like to prevent students to
> access this path, so that they don't get this stuff almost for free ;-)
>
> It's possible to restrict the access for https and svn+ssh using the
> procedure described above. But what about local access via file://? You
> wrote above about the hook scripts, the idea came to my mind, one could
> use some hooks to prevent file access, but by default there exist
> templates for pre-commit and pre-lock hooks... don't know if it might help.

your question makes no sense.. if you have the repo chown'd to
apache:svn and chmod'd to 0750 or similar then noone else (ie, people
who aren't the apache user or in the svn group) will have access to the
repository via file:///

>>> 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?
>> 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
>>
>> 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.
> yes, it is of fsfs type.
>>> did function as before. Magical robustness ;-)
>> The only thing I can think of would be to remove the files
>> libsvn_ra_local-1.* from ${prefix}/lib after installation is done.
>>
>> 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.
>>
> wow! Once again, thanks a lot for explanation. I was wondered myself why
> it did work (when you actually don't want it ;-) ), so I have to double
> check where it gets ra_local libraries, we have version 1.4.3 installed
> now, and before it was 1.2.3, so it might be the old libs are still
> lying around somewhere.
>

---------------------------------------------------------------------
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-05 20:02:08 CEST

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.