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

Re: Add $authenticated to group definition

From: Tom Ghyselinck <tom.ghyselinck_at_excentis.com>
Date: Fri, 16 Jan 2015 13:55:19 +0100

Hi Brane,

Thank you for the quick reply!

Our point is that we would like define groups as
        <service>-<access>-<group>

I.e. For our subversion service:
        vcs-r-some_group
defines that "some_group" has "read" access for the subversion
repository.

- Some repositories allow read access to a select number of users.
- Other repositories allow read access to all "authenticated
users" (i.e. $authenticated).

When we could add "$authenticated" to the "vcs-r-some_group",
then this can be controlled by a single group while now, we need to add
both.

We added the $authenticated = r line to the relevant paths in the
affected repository's authz.

With best regards,
Tom.

On vr, 2015-01-16 at 10:57 +0100, Branko Čibej wrote:
> On 16.01.2015 08:06, Tom Ghyselinck wrote:
> > Hi,
> >
> > We are using subversion 1.8.8 (r1568071) server on Ubuntu 14.04.
> >
> > I need to add "$authenticated" to the group since this is required for
> > our company generic group definitions.
>
> I'm having a hard time understanding this requirement. Any concrete user
> or group you mention in a rule will only take effect for authenticated
> connections anyway.
>
> > We created an authz file with group definitions as follows:
> >
> > [groups]
> > myreaders = $authenticated
> >
> > [/]
> > * =
> >
> > [/path1]
> > $authenticated = r
> >
> > [/path2]
> > @myreaders = r
> >
> > [/path3]
> > # I know, this is actually a user definition
> > myreaders = r
> >
> >
> > It looks like it is not possible or not allowed to add the
> > "$authenticated" token to a group definition:
> > - Using it in /path1 is fine (as documented)
> > - I expect it also to work in /path2, but it's not.
> >
> > $ /usr/bin/svnauthz accessof --username=someuser --path=/path1
> > ~/test.authz
> > r
> >
> > $ /usr/bin/svnauthz accessof --username=someuser --path=/path2
> > ~/test.authz
> > no
> >
> > $ /usr/bin/svnauthz accessof --username=someuser --path=/path3
> > ~/test.authz
> > no
> >
> > $ /usr/bin/svnauthz accessof --username=myreaders --path=/path1
> > ~/test.authz
> > r
> >
> > $ /usr/bin/svnauthz accessof --username=myreaders --path=/path2
> > ~/test.authz
> > no
> >
> > $ /usr/bin/svnauthz accessof --username=myreaders --path=/path3
> > ~/test.authz
> > # (Here it matches the "user" myreaders)
> > r
> >
> >
> > I couldn't find any documentation whether or not it is possible and/or
> > allowed.
>
> If you read
>
> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html
>
> you'll find that you can define groups that contain users, aliases and
> other groups. $authenticated and $anonymous are magic tokens that do not
> belong to any of those categories.
>
> The point is that group memberships are completely defined when the
> authz file is parsed, but $authenticated and $anonymous do not refer to
> users but to connection states when the authorization check is being done.
>
> > Can someone confirm if this is expected to work or not?
>
> It is not expected to work.
>
> > If not, is there a workaround to add "$authenticated" to a group?
>
> You don't need a workaround. Just change your configuration like this,
> for example:
>
> [/path2]
> @myreaders = r
> $authenticated = r
>
> But, as I said above: this is redundant. The "@myreaders=r" entry only
> takes effect if the connection is authenticated; if it's an anonymous
> connection, there's no user name and therefore no group membership, so
> you may as well omit the "@myreaders=r" entry from the authz rule.
>
> -- Brane

-- 
________________________________________________________________________
| tom.ghyselinck_at_excentis.com
|
| Tom Ghyselinck
| Senior Engineer
| Excentis N.V.
| Gildestraat 8 B-9000 Ghent, Belgium
| Tel: +32 9 269 22 91 - Fax: +32 9 329 31 74
________________________________________________________________________
Received on 2015-01-16 13:57:41 CET

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.