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

Re: subversion acls

From: Anand Sachdev <anand.sachdev_at_gmail.com>
Date: 2006-02-21 09:29:52 CET

Rahul,
   I have it working now, do you want to see my config files?
Anand

On 2/21/06, Michael Hertling <hertling@ikp.tu-darmstadt.de> wrote:
>
> On Fri, 17 Feb 2006, Rahul S wrote:
> > [...] I am trying to set up directory-level
> > access control in the repository. The 'conf/authz' is as follows:
> > [/]
> > * = r
> >
> > [/abc/trunk/src]
> > * =
> > user1 = rw
> >
> > But when I try to checkout the source as the user 'user1', I get the
> > following error:
> > "svn: Not authorized to open root of edit operation"
>
> Hi Rahul, dear svn community,
>
> using the new path-based authorization feature of svnserve 1.3.0 - no
> Apache involved - I've encountered a similar problem which appears to
> have the same origin. Having 'svnuser' in 'conf/passwd' of repository
> 'repos', blanket access rules in 'conf/svnserve.conf' set to defaults
> 'anon-access=read' and 'auth-access=write', resp., it was my intention
> to disable anonymous access to the repository's root and explicitly
> enable it for selected paths, i.e. in 'conf/authz':
>
> [/]
> * =
> svnuser = r
> [/trunk]
> * = r
> svnuser = rw
>
> The above lines should allow authenticated read access to '/' for
> 'svnuser' and anonymous read access to '/trunk'. The command line
>
> svn co --username svnuser svn://localhost/repos workdir
>
> correctly challenges for authentication as user 'svnuser', but then
> terminates with "svn: Not authorized to open root of edit operation",
> leaving a working directory 'workdir' with only a '.svn' subdirectory
> therein. In particular, the latter strikes me as faulty behaviour since
> svn usually doesn't create a working directory if a checkout operation
> aborts due to failed authentication.
>
> Furthermore, in case of anonymous access being forbidden in general by
> 'anon-access=none' in 'conf/svnserve.conf' with 'conf/authz' unchanged,
> the above command works as expected: challenge for authentication and
> subsequent checkout. This leads to the - imho - somewhat paradoxical
> situation where one has to tighten the rules for anonymous access in
> order to gain the desired authenticated access. Nevertheless, even if
> it's the normal method of svn to operate anonymously as far as possible,
> it should manage to perform the checkout mentioned at first after it
> receives a valid authentication. To me, it seems as if svn tries to
> perform the checkout anonymously even after the need for authentication
> has been realized and caused the proper challenge, and finally stumbles
> across the entirety of access rules.
>
> @ Rahul: Try your desired operations with 'anon-access=none' and see if
> this succeeds. Provided that you're absolutely in need of an anonymous
> repository handling, my suggestion is to add an account without password
> to the repository, e.g. 'guest', and give the access rights originally
> intended for the anonymous user to it. This workaround will complicate
> access rules in 'conf/authz' though, but allows at least anonymous-like
> operations, e.g.:
>
> svn co --username guest --password '' svn://<host>/<repos>/<path>
>
> @ svn developers: I'd like to ask if the behaviour described above and
> earlier by Rahul is really intented w.r.t. svnserve's new path-based
> authorization and I'm overlooking something, or if it's indeed
> questionable.
>
> Any suggestions, clarifications etc. will be greatly appreciated.
>
> Regards
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Received on Tue Feb 21 09:31:03 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.