What the "anon-access = none" option does is remove the ANONYMOUS
mech from the list of SASL mechs offered by svnserve (I see this in
tcpflow). If this mech is present in the mech list, the svn client
does not bother to authenticate even if a valid Kerberos ticket is
available.
If the svn client had an option to enforce authentication even if
offered the ANONYMOUS mech by the server, the problem would be solved
IMHO.
Which boils down to another problem I stated here about SASL mech
selection: http://tinyurl.com/4ntesca
John Conrad wrote:
> For what it's worth, I have run into the same problem and the only
> solution I have found is to switch to a different access method. As
> best as I can tell svnserve is simply not an option when trying to set
> up a repository with path based authentication when select areas are
> flagged inaccessible to anonymous users. I have recently switched from
> a svnserve to apache based setup and using the exact same authz-db
> file, svnserve failed to return "svn log" results for protected paths
> while apache worked correctly.
>
> The below issue on the SVN tracker I think refers to this issue and it
> has been open since Oct. 2009:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3516
>
> Anyway, I could be totally wrong here, but I do not think what you
> want to do is possible with svnserve. I hope I am mistaken, but if
> not, sorry to be the bearer of bad news.
>
> On Thu, Feb 10, 2011 at 9:30 PM, Victor Sudakov
> <sudakov_at_sibptus.tomsk.ru> wrote:
> > The problem is probably in the following. When anon-access is other
> > than "none", svnserve does not request authentication for some
> > important operations like "svn log", and I have found no way to force
> > it to request authentication. This effectively breaks path based
> > authorization.
> >
> > I have found some tricky solutions for the http access method (like
> > defining two aliases for the same repository), but none for the
> > svnserve method. Any help?
> >
> > Victor Sudakov wrote:
> >>
> >> I am trying to setup the following policy: a private repository with
> >> some public paths. Is such configuration supported at all?
> >>
> >> The following configuration:
> >>
> >> ========== conf/svnserve.conf:
> >> anon-access = read
> >> auth-access = write
> >> authz-db = authz
> >>
> >> ========== conf/authz:
> >> [/]
> >> @noc = rw
> >>
> >> [/foo]
> >> $anonymous = r
> >> $authenticated = rw
> >>
> >> does not work. A valid user from the noc group receives the following reply:
> >>
> >> $ svn diff -c2237 www.txt
> >> svn: Unreadable path encountered; access denied
> >>
> >> If I change "anon-access = read" to "anon-access = none", it begins to
> >> work for the valid user, but there is no anonymous access to anyone
> >> even to svn://myserver/foo despite the "$anonymous = r" clause.
> >>
> >> What am I doing wrong?
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
sip:sudakov_at_sibptus.tomsk.ru
Received on 2011-02-11 07:41:48 CET