Re: [viewvc-users] viewvc + path-based authorization

Julian wrote:
> Thanks - got the "authorizer = svnauthz" part added and I'm almost there but have hit another problem - I currently have FULL r/w access to the whole repos tree. So my entry in the svn authz access file is:
> 
> [repos:/]
> julian = rw
> 
> If I remove myself from the svnauthz access file and restart Apache then I cannot get to the repos - the error I get is "An Exception Has Occurred, The root "repos" is unknown...etc" which is good.
> 
> But we also have users that only need to be able to see certain branches under the repos tree - it's now this that I cannot get to work. So in my svn authz access file if I have the following:
> 
> [repos:/project1]
> julian = rw
> 
> I'd expect I can get to /project1 but NOT even see any other branches such as project2, project3 etc?
> 
> But what I actually get in my browser is:
> 
> An Exception Has Occurred
> Unknown location: /
> HTTP Response Status
> 404 Not Found

ViewVC is going to behave quite literally regarding the accessibility of
paths in the repository, just as Subversion does.  So if all you have in
your authz file is:

   [repos:/project1]
   julian = rw

Then attempts to hit the root directory listing of your repository in ViewVC
will fail.  If, however, you navigate directly to the URL of the "project1"
directory, though, you should see it.

<sidebar>

And here is where we find ourselves having an interesting conversation about
access rights and their meanings.

On the one hand, Subversion itself will behave in the same way described
above.  If you don't have read access to the root of the repository, you
can't checkout from that directory or otherwise query it.  So ViewVC is
being consistent with Subversion in that regard.

On the other hand, it could be considered ridiculous that ViewVC doesn't at
least let you navigate from the root down to the directories you are allowed
to see.  It's hardly a "security leak" for a person who knows they have
access to "/some/deep/dir" to figure out that there exist directories at
"/", "/some", and "/some/deep", right?

At CollabNet, our ViewVC integration (which uses a completely custom bit of
authorization logic) takes the "other hand" approach.  If you have access to
"/some/deep/dir", ViewVC lets you view "/" and see only the one child
"some"; you can view "/some" but only its one child "deep"; and you can view
"/some/deep"; but only its one child "dir".  And of course, once you get
down into "/some/deep/dir", you can see everything.  (Recently, I proposed
to the Subversion development community that Subversion adopt this approach,
too -- allowing everyone to checkout any directory so long as they have read
access to any child or [great]grandchild of that directory, though only
skeletally populating the directories they don't have direct read access to.)

I didn't take this approach with open-source ViewVC's first pass at
authorization logic because I felt it better to err on the side of opacity
for the paranoid admin, because I wanted match Subversion's authz semantics
more literally, because the approach is a bit simpler, and because the
performance is expected to be better.  But I did this knowing that I might
relax the behavior in the future.

</sidebar>

So, what does this mean for you?  Well, it means you either have to just
deal with the limitation for now, or it means you have to tweak your authz
files to grant the higher-level read access while explicitly denying access
to the subdirs you shouldn't have access to.

   [repos:/]
   julian = r

   [repos:/project1]
   julian = rw

   [repos:/project2]
   julian =

   [repos:/project3]
   julian =

-- 
C. Michael Pilato <[email protected]>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

------------------------------------------------------
http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4255&dsMessageId=2331059

To unsubscribe from this discussion, e-mail: [[email protected]].

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkoUFXQACgkQokEGqRcG/W5/5ACgpsGLd6XB222QQEUOykSDSfsT
1DoAn1X5ip1Xc5rSqRebdwNdKJbfYZI+
=UMqy
-----END PGP SIGNATURE-----