Hello,
Don't forget to add "users_at_subversion.tigris.org" to the CC: area of
your email or you only send replies to me, rather than the mailing list :)
In Apache, allowing read access to root but only the right user to their
folder may be a bit easier (depending on how many users you have):
<Location /svn>
...
</Location>
<Location /svn/userA>
Require [userA]
</Location>
<Location /svn/userB>
Require [userB]
</Location>
...
Obviously that doesn't help if you're not using Apache for access
control, but I figured it'd be worth a shot. That's a rather naive way
of doing it; there may be better methods.
Additionally, this solves the symptoms but not the cause; your curious
case of revision history being unaccessible if your users don't have
read access at root. I am not familiar with this problem, but if others
on this list have any ideas, maybe the output from some svn command-line
log requests and a simplified layout of the repository could help debug
this issue. Of course, if you succeed in limiting access properly while
still allowing read access at root, you may wish to just leave it if it
works.
Hope this helps!
M.S.Bachler wrote:
>
> Hi!
>
>
>
> Thanks for the reply.
>
> I don't think you have quite got it, but I didn't explain it well.
>
>
>
> "It seems the error is that your users cannot see history outside
> their new controlled space, correct?"
>
>
>
> They cannot see the revision histories in their own folders (control
> space), to which they have read/write access.
>
> This is odd. But when those revisions where created on the other
> server, they all had read access from root down.
>
> So even though they still have read/write to their own folders now,
> the same as they had on the other server, they now only had read/write
> to their folders and not read from root.
>
> Somehow this change of their permissions meant that they could no
> longer see their own revision histories in their own folders created
> when they had also read access from root.
>
> If I give then read access from root they can see their own revision
> histories again.
>
>
>
> However, you have given me an idea with the comment about restricting
> access to other people's folders, but having read access from root.
>
> That might work.
>
> They currently have read access from root so they can see their
> revision histories, but they can also see everyone else's folders.
>
> I will try restricting them from each others folders (a bit messy in
> svnaccess, but worth a try) and see if they can still see their
> revision histories.
>
>
>
> Thanks for the idea.
>
>
>
> I thought about a dump, but wanted to see if there was an alternative
> before I did this, as it would be quite disruptive.
>
>
>
> Thanks again.
>
>
>
> Michelle
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* Jake Stone [mailto:jake.the.stone_at_gmail.com]
> *Sent:* 19 October 2009 20:24
> *To:* M.S.Bachler
> *Subject:* Re: revision history and permissions
>
>
>
> M.S.Bachler wrote:
>
> Hi!
>
>
>
> I recently moved a subversion folder from one server to another.
>
> I wanted to implement folder level permissions using Apache and needed
> to upgrade for it to work, so I.T. built me a new server while they
> where at it.
>
>
>
> Once copied over, all seemed well.
>
> I restructured the folders into public and private areas, and then
> added my users on the new server and their new folder level permissions.
>
> It all seemed to work fine.
>
> Each user could only read/write to their folder now.
>
> However, they could no longer see their revision histories.
>
> They needed read permissions from the root down to see them again
> (This is what they had on the old machine).
>
>
>
> So it seems that the revisions somehow know the user's permission
> level has changed, and even though they are only trying to access
> revisions for files they have read/write access to, it still won't let
> them see them without read permissions from the top down.
>
>
>
> My question is how do the permissions work with the revisions?
>
> Is there anyway to fix this access issue from the svn admin commands
> (I don't really want then all to have read to everything -- that was
> the point of the move!).
>
>
>
> Thanks
>
>
>
> Michelle
>
>
>
> ------------------------------------------------------------------------
>
>
> The Open University is incorporated by Royal Charter (RC 000391), an
> exempt charity in England & Wales and a charity registered in Scotland
> (SC 038302).
>
>
> It seems the error is that your users cannot see history outside their
> new controlled space, correct? Maybe because their projects used to be
> in a different folder that they no longer have access to? It may be
> possible to give everyone read access at root, but restrict read
> access in any sensitive sub-folders (which you seem to have already
> done). You could experiment by giving yourself or a test user the
> root-read permission; if your Apache configuration is right you should
> be able to read the root (and wherever the projects used to be)
> without accessing anyone's private folder, which would be your desired
> behavior and may fix the missing history problem.
>
> An alternative may be using the svn dump commands to a new repository,
> which would re-commit the entire history into the desired private
> folders. That may be a little more of a manual task however, and I am
> not as familiar with those tools (the svn book has comprehensive
> documentation). It's also possible I'm not understanding the problem
> correctly; if that's the case, try elaborating on the repository
> layout (old and new) in a reply.
>
>
> ------------------------------------------------------------------------
>
> The Open University is incorporated by Royal Charter (RC 000391), an
> exempt charity in England & Wales and a charity registered in Scotland
> (SC 038302).
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2409493
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-20 20:35:09 CEST