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

Re: authz question

From: Dan Crosta <dcrosta_at_gmail.com>
Date: 2006-09-26 16:34:03 CEST

OK, here's what I currently have, and I think it should do what I want:

[/]
dcrosta = rw

[/trunk/module]
dcrosta = rw
* = r

however, the svn client is still prompting me for a username, which
leads me to believe that I have misconfigured apache somehow, so that
it is not allowing any kind of anonymous access (i tested this by
removing all rules and simply putting * = rw in [/]). here's my apache
config, does anything look obviously wrong?

----
    <Location "/src">
        DAV svn
        SVNPath /Users/dcrosta/Data/svn
        AuthZSVNAccessFile /Users/dcrosta/Sites/trac/conf/trac.authz
        # try anonymous access first (with AuthZ),
        # then resort to authenticated access
        Satisfy Any
        Require valid-user
        AuthType Basic
        AuthName "Dan's Source"
        AuthUserFile /Users/dcrosta/Sites/trac/conf/trac.htpasswd
    </Location>
----
Interestingly, I can use a browser to browse /trunk/module without any
trouble, and get prompted for a username and password whenever I try
to go outside of that -- why is the svn client acting differently?
I've tested it with svn clients on a few different architectures and
versions (cygwin @ 1.3.2, OS X @ 1.2.3), all with no luck.
- d
On 9/25/06, Shaun Johnson <shaun.johnson@gmail.com> wrote:
> Dan,
>
> If I read your original question right you are assuming that Subversion will
> grant you rw access to the entire tree because you have assigned your rw at
> the root. This is not the case. Subversion starts at the bottom and works
> it's way up until it finds a rule that matches your account.
>
> In your original example you had:
>
> [/]
> dcrosta = rw
>
> [/trunk]
> * = r
>
> [/trunk/module]
> * = r
>
> [/trunk/othermod]
> * =
>
> [/trunk/thirdmod]
> * =
>
> If you (dcrosta) try to access /trunk/othermod Subversion will look in the
> authz file for a path that matches /trunk/othermod with an access rule that
> matches your account. In this case /trunk/othermod matches the path and *
> matches all users, which includes you. Therefore, you get "no access" to
> this path.
>
> If you try to access /trunk/project/test Subversion will look in the authz
> file for /trunk/project/test and will not find a match. So it moves up a
> level and checks for /trunk/project. Again, no luck. It moves up another
> level and tries /trunk. That path matches and the * access rule matches all
> users so Subversion gives you read access to /trunk/project/test.
>
> Now on the second part of your last email. Subversion will use the most
> specific access rule that matches your account. It then moves out to the
> more general rules.
>
> For example if we have the following:
>
> [/trunk]
> * =
> @somegroup = r
> dcrosta = rw
>
> If you access /trunk with dcrosta you will get rw access, since it is the
> most specific rule that matches your account.
>
> The only thing I don't know is what Subversion will do in this situation:
>
> [/branches]
> @developers = rw
> @managers = r
>
> If your account is a member of both developers and managers, I don't have
> any idea what level of access you end up with. I hope that you would get rw,
> but I just don't know.
>
> Hope this helps.
>
> Shaun
>
>
> On 9/25/06, Dan Crosta <dcrosta@gmail.com> wrote:
> >
> > OK -- I've re-read that section, and it sounds like this
> > configuration, though verbose, ought to work:
> >
> > ----
> > [/]
> > dcrosta = rw
> > * = r
> >
> > [/trunk]
> > * = r
> >
> > [/trunk/module]
> > * = r
> >
> > [/trunk/othermod]
> > * =
> > ----
> >
> > what it actually seems to be doing is overriding it so that I only
> > have acess to /, /trunk and /trunk/dtk, and so that *nobody* has
> > access to /trunk/othermod. In other words, * matches everyone and more
> > general definitions are overriding the more specific ones. order does
> > not seem to matter, at least not so long as the definitions are
> > unique.
> >
> > does anyone know if this is correct behavior of mod_dav_svn (or
> > whatever is actually responsible for applying rules for authz)? I have
> > 1.2.3 installed.
> >
> > - d
> >
> >
> > On 9/25/06, Mark <mark@mitsein.net> wrote:
> > > You're fine.  Please see:
> > >
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.perdir
> > >
> > > It looks like if you don't use the SVNParentPath setting, you don't
> > > need to put the repository name in the authz setting.
> > >
> > > On 9/25/06, Dan Crosta < dcrosta@gmail.com> wrote:
> > > > (apologies, mark, for the double mail, i keep expecting gmail to
> reply-all...)
> > > >
> > > > Maybe I've been confusing the terminology: there is only one
> > > > repository, but several... well, CVS called the modules, but I guess
> > > > they are actually paths within the repository, is that right? That is,
> > > > the repository has:
> > > >
> > > > /tags
> > > > /branches
> > > > /trunk
> > > >  /module
> > > >  /othermodule
> > > >  /thirdmodule
> > > >
> > > > - d
> > > >
> > > >
> > > > On 9/25/06, Mark <mark@mitsein.net> wrote:
> > > > > Yes, because you are accessing one authz file for many repositories,
> right?
> > > > >
> > > > > On 9/25/06, Dan Crosta <dcrosta@gmail.com> wrote:
> > > > > > Is this true even if I'm using SVNPath in httpd.conf, not
> SVNParentPath?
> > > > > >
> > > > > > - d
> > > > > >
> > > > > > On 9/25/06, Dan Crosta <dcrosta@gmail.com> wrote:
> > > > > > > Is this true even if I'm using SVNPath in httpd.conf, not
> SVNParentPath?
> > > > > > >
> > > > > > > - d
> > > > > > >
> > > > > > > On 9/25/06, Mark <mark@mitsein.net > wrote:
> > > > > > > > the authz config for mod_svn_authz is slightly different than
> for
> > > > > > > > svnserve.  You need to specify the name of the repository.  So
> if your
> > > > > > > > repository name is goodstuff:
> > > > > > > > [/]
> > > > > > > > dcrosta = rw
> > > > > > > >
> > > > > > > > [goodstuff:/trunk]
> > > > > > > > * =r
> > > > > > > >
> > > > > > > > etc
> > > > > > > >
> > > > > > > > On 9/25/06, Dan Crosta <dcrosta@gmail.com> wrote:
> > > > > > > > > i have a repository i use to track all my source code, some
> of which i
> > > > > > > > > want to make publicly available, but most of which i want to
> keep
> > > > > > > > > private. i'm using mod_dav_svn and mod_svn_authz for
> repository access
> > > > > > > > > and control, and have followed the pattern at
> svnbook.red-bean.com for
> > > > > > > > > anonymous or authenticated access, with an authz file like
> this:
> > > > > > > > >
> > > > > > > > > ----
> > > > > > > > >
> > > > > > > > > [/]
> > > > > > > > > dcrosta = rw
> > > > > > > > >
> > > > > > > > > [/trunk]
> > > > > > > > > * = r
> > > > > > > > >
> > > > > > > > > [/trunk/module]
> > > > > > > > > * = r
> > > > > > > > >
> > > > > > > > > [/trunk/othermod]
> > > > > > > > > * =
> > > > > > > > >
> > > > > > > > > [/trunk/thirdmod]
> > > > > > > > > * =
> > > > > > > > >
> > > > > > > > > ----
> > > > > > > > >
> > > > > > > > > which, if i understand correctly, should allow anonymous
> access to
> > > > > > > > > /trunk/module, but not to any other part of the repository,
> and allow
> > > > > > > > > me access to any of the repository. however, this is not
> working.
> > > > > > > > > checkout and export are prompting for a password, but the
> list command
> > > > > > > > > quite happily lists contents of /trunk/module. have i messed
> something
> > > > > > > > > up?
> > > > > > > > >
> > > > > > > > > alternately, is there an easier way to give access to just a
> portion
> > > > > > > > > of the repository? i tried leaving out the section for
> [/trunk] and
> > > > > > > > > for [/trunk/othermod] and [/trunk/thirdmod] ... that
> configuration
> > > > > > > > > doesn't allow anonymous users to list /trunk (fine by me),
> it does
> > > > > > > > > allow anonymous to list /trunk/module (good), but still
> won't allow
> > > > > > > > > anonymous to check out from anywhere.
> > > > > > > > >
> > > > > > > > > - d
> > > > > > > > >
> > > > > > > > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail:
> users-unsubscribe@subversion.tigris.org
> > > > > > > > > For additional commands, e-mail:
> users-help@subversion.tigris.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Mark
> > > > > > > > "Blessed is he who finds happiness in his own foolishness, for
> he will
> > > > > > > > always be happy."
> > > > > > > >
> > > > > > > >
> ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> users-unsubscribe@subversion.tigris.org
> > > > > > > > For additional commands, e-mail:
> users-help@subversion.tigris.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> users-unsubscribe@subversion.tigris.org
> > > > > > For additional commands, e-mail:
> users-help@subversion.tigris.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Mark
> > > > > "Blessed is he who finds happiness in his own foolishness, for he
> will
> > > > > always be happy."
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> users-unsubscribe@subversion.tigris.org
> > > > > For additional commands, e-mail:
> users-help@subversion.tigris.org
> > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> users-unsubscribe@subversion.tigris.org
> > > > For additional commands, e-mail:
> users-help@subversion.tigris.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Mark
> > > "Blessed is he who finds happiness in his own foolishness, for he will
> > > always be happy."
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> users-unsubscribe@subversion.tigris.org
> > > For additional commands, e-mail:
> users-help@subversion.tigris.org
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail:
> users-help@subversion.tigris.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 26 16:34:59 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.