>> 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.
>> 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.
--
Dipl.-Ing. Anton Pervukhin Lehrstuhl fuer Bioinformatik
Institut fuer Informatik, Friedrich-Schiller-Universitaet Jena
Ernst-Abbe-Platz 2, 07743 Jena, Germany
Office 3426, Phone +49 (0)3641 9-46454, Fax +49 (0)3641 9-46452
http://bio.informatik.uni-jena.de/
---------------------------------------------------------------------
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 19:48:03 CEST