0

VisualSVN 2.5.16 on a server, Tortoise SVN 1.8.1 as a client on a development machine.

I've set up permissions on the VisualSVN Server Manger for someone to give them access to a repo. The permissions seem to reflect in the 'browse repo' interface, but not in the update/commit actions from TortoiseSVN when it talks to the VisualSVN server.

Example: I went to the project I've been working on for months and test - remove my permissions in VisualSVN server manager so all Everyone has No Access, and the developer group has No Access. IE no on has access at this point. Yet I can still create a test file, and commit it to the repo. Then go and delete the file form the repo and commit that. I don't seem to be able to revoke permissions for me to read or write to the repo.

The change has made the repository now show up in the "Repository Browser" of TortoiseSVN (ie I cannot see the tree branch I removed my permissions to), but the update/commit actions from the Windows 7 file explorer context menu still work just fine.

I'm wondering if the same sort of oddness is what is preventing my colleague from accessing the repository to commit changes, despite him having been explicitly been given read/write permissions to the other repository he is working on.

The root problem I'm trying to solve is why a colleague has read-only access to a part of the repository, where the only two modes of access granted are "no access" for 'everyone' and "read/write" access for our dev group and him explicitly. He is authenticating against VisualSVN using that explicit login, but only gets read-only access. According to the VisualSVN docs, by virtue of his name being explicitly being granted read/write access, that would grant him that over any inheritance or the 'everyone' access on the repository folder.

Something odd is at play between VisualSVN Standard Edition with explicit accounts and TortoiseSVN on Windows 7.

  • have you tried the Visual SVN server 2.7 or 3.0? Also update TSVN to 1.8.8 – magicandre1981 Nov 11 '14 at 4:47
0

Example: I went to the project I've been working on for months and test - remove my permissions in VisualSVN server manager so all Everyone has No Access, and the developer group has No Access. IE no on has access at this point. Yet I can still create a test file, and commit it to the repo. Then go and delete the file form the repo and commit that. I don't seem to be able to revoke permissions for me to read or write to the repo.

I guess that you have an access rule at the root level that gives your account Read / Write access. Do you have Read / Write rule on the parent level? E.g. a rule for Everyone. If you do, then switch the access to No Access or remove the rule completely. Otherwise, the Read / Write access rule for Everyone can become effective if you enter a repository URL using invalid case of characters.

Prior to version 1.7, Apache Subversion treated repository names and paths in a case-insensitive fashion for the purposes of access control, converting them to lower case internally before comparing them against the contents of your access file. It now does these comparisons case-sensitively. See Apache Subversion 1.7. Release Notes at http://subversion.apache.org/docs/release-notes/1.7.html#case-sensitive-authz.

To resolve the possible security issues you should remove everyone's "read / write" access from the repositories root.

NOTE: The issue affects only Subversion authentication/authorization type and doesn't reproduce with Windows Authentication/authorization (Basic and/or Integrated). Does not reproduce with VisualSVN Server 2.6 and newer.

VisualSVN 2.5.16 on a server, Tortoise SVN 1.8.1 as a client on a development machine.

It makes sense to keep the server and the client updated, at least within the release you currently use:

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.