Subversion: Access forbidden: Cannot commit within tortoise svn client window when I do not have read access to root

1
votes

I know subversion this type of question has been asked many times but various solutions have not worked and the specific setup has not been the same.

We are using Tortoise SVN as the client. When users have read/write access to a subfolder in subversion, say, /project1 and read access to root (/), everything works fine in the working copy and within the tortoise svn client window.

However, if I remove read access from root (/) leaving just the read/write access to /project1, users cannot commit to project1 within the tortoise client window. We can commit when doing so withing our working copy, but not within the client window.

What is going on here?

Windows 7 64bit, tortise svn 64bit 1.7.10 Subversion server on apache running: "Powered by Subversion version 1.6.11 (r934486)."

1
svntortoisesvn
Ugh, my Windows is rusty, but shouldn't users at least be able to list / before they can access /project1? That's how it would work on Linux... - Wrikken
@Wrikken perhaps that's why it works when users have read access. But why then does it work for the working copy but not within the client window? Really though, I thought users didn't need root access, I thought they would have access to whatever sub directory in subversion you give them. Also, why would read on a sub directory work but not write if users don't have root access? - Patrick Bateman
If you can't list root in linux, it wouldn't work (no reading/writing anywhere). However, I'm unfamiliar with the design strategy of Windows permissions, so I'll leave those questions to someone more suited. - Wrikken
@Wrikken - A HA! there are two pieces here that I failed to see and you helped with that, I will add this to an answer. We have [/] set to read and we have [repo:/project1] set to rw but we never added [repo:/] rights; once I added [repo:/] and set that to read only, everything was operational. - Patrick Bateman
Perhaps you could clarify in the question what I learnt from your answer, namely that you are talking about access granted by the repository configuration in svnauthorization.conf? I suppose it is obvious that / must refer to that, but I couldn’t think what you meant at first. I also do not know what you mean by committing “within our working copy” and “within the client window”. - PJTraill

1 Answers

3
votes

With Wrikken shaking my brain I found that this was a misconfiguration of our svnauthorization.conf.

I should have mentioned that we are using CollabNet subversion and this link helped too: http://www.rahulsingla.com/blog/2012/01/collabnet-subversion-restricting-user-access-to-repositories

We basically had this setup:

[groups]
admins= me, domain\me
users= you, domain\you

[/]
@admins = rw
@users = r

[repo:/project1]
@users = rw

[repo:/project2]
@users = r

You see the problem? I didn't, but here it is, we gave read access to the top-level root when we should have given read access to the repo root:

[/]
@admins = rw

[repo:/]
@users = r

[repo:/project1]
@users = rw

[repo:/project2]
@users = r