[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: authz: what has precidence when user is multiply referenced for a particular path?

From: Lieven Govaerts <lgo_at_mobsol.be>
Date: 2006-05-19 17:03:50 CEST


> -----Original Message-----
> From: Frank Gruman [mailto:fgatwork@verizon.net]
> Sent: vrijdag 19 mei 2006 16:44
> >
> >
> You are working under the assumption that he uses http://. I
> myself do, but I still see many others out there who use
> svn:// access. Which is trying to read only the
> authorization file.

The first part of my mail is applicable to both mod_authz_svn and svnserve.
I showed also how to achieve the solution for Greg's problem with
mod_authz_svn. You can achieve the same thing with svnserve when specifying
the 'anon-access = read' option in svnserve.conf

>And I am confused by what you just
> stated. You said that it "skips" the first line for read
> access and grants access based on the second line. Does that
> mean that it does parse the first line or does not??

Yes it does, sorry for the bad wording. In fact, svn will ask the authz
subsystem if a user has read or write access on a certain folder in the
repository. The authz system will then start parsing sections
([A001:/branches/DEV_...]) until it finds one that matches the folder. Then
it will parse all lines in the section, until it finds one that grants the
user the requested access (ie. read or write). Simply said, with each line
you can add extra rights for users, but you can't take them away.

> This leads back to my previous post where I think _EVERY_ row
> in the group should get parsed, and the order in which they
> are entered is the order of precedence. So you could grant
> access to everyone and take away from the one or two that
> don't need it or any other of the massive number of
> permission scenarios we run into.

And at first sight I agree with you, although I'm not aware now of the
consequences. As I said in my other email, I'm not aware of the reasons why
people have implemented it the way it is now, maybe they had some very valid
reasons besides performance to do it this way.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 19 17:11:33 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.