Possible security issue for people updating from 0.11 to 0.12

26 views
Skip to first unread message

HeX

unread,
Jul 14, 2010, 10:04:14 AM7/14/10
to Trac Development
Hi,

After upgrading to from 0.11 to 0.12 I actually spend a busy day
figuring out how to use the new way of fine grained permission policy.
I ended up with some annoying and some actually scaring results I like
to share. Mind that I could be wrong in how I used the new setup so
please feel free to correct me or chase me away to the users group.

1.) Combining authz file of svn access and trac access will fail since
svn won't like ANY part of the Trac specific definitions in the authz
files and will therefore break.
-> Solution: two separate authz files, one for the SVN access rules
and one for the Trac rules, this means actually duplicatiing the user
and group defintions, but see 2

2.) AFAICT fine grained permisson access
(tracopt.perm.authz_policy.*=true) is not group aware (see #4224). In
detail I found out that only anonyous and authenicated are recognised.
All other groups in the authz file are simply ignored. This makes it
very hard to use the fine grained permissions in a proper way.

3.) The worst thing is that Trac will obey non of the svn permissions
given by the authz file that controls the svn access. Anybody with
BROWSER_VIEW will now be able to browse the WHOLE source tree
regardless what the svn auhtz defines. In my case I had to take away
BROWSER_VIEW from all anonymous users (very irritating) just I have
some private folders in the repo.

The worrying thing really is that I wasn't aware of problem 3.) and
only found out by accident. Such a change should have been anounced in
BIG RED letters before the release and the inability to assign
permissions to groups (this worked before via authzgroups plugin)
should have been a BLOCKER for 0.12.

Maybe I've just done the configuration wrong and all the above items
can be handled (in that case I'm eager to learn how ;) ).

Regards,
HeX

Remy Blank

unread,
Jul 20, 2010, 11:19:45 AM7/20/10
to trac...@googlegroups.com
HeX wrote:
> 1.) Combining authz file of svn access and trac access will fail since
> svn won't like ANY part of the Trac specific definitions in the authz
> files and will therefore break.
> -> Solution: two separate authz files, one for the SVN access rules
> and one for the Trac rules, this means actually duplicatiing the user
> and group defintions, but see 2

This has always been the case AFAIK. Or in other words, it has never
been intended that the SVN authz file and the authz file for
fine-grained permissions should be merged.

> 2.) AFAICT fine grained permisson access
> (tracopt.perm.authz_policy.*=true) is not group aware (see #4224). In
> detail I found out that only anonyous and authenicated are recognised.
> All other groups in the authz file are simply ignored. This makes it
> very hard to use the fine grained permissions in a proper way.

That seems to be the case, yes. The authz_policy module is in need of a
rewrite.

> 3.) The worst thing is that Trac will obey non of the svn permissions
> given by the authz file that controls the svn access. Anybody with
> BROWSER_VIEW will now be able to browse the WHOLE source tree
> regardless what the svn auhtz defines. In my case I had to take away
> BROWSER_VIEW from all anonymous users (very irritating) just I have
> some private folders in the repo.

That's surprising. Did you set "[trac] authz_file" and "[trac]
autz_module_name" correctly in trac.ini? Do you use multiple
repositories? Are your repositories named the same in Trac and in the
authz file?

> The worrying thing really is that I wasn't aware of problem 3.) and
> only found out by accident. Such a change should have been anounced in
> BIG RED letters before the release

AFAIR, there has been no change in the configuration, only in the
implementation, so if it was working before, it should still be working
now. Except if I broke something, of course :)

> and the inability to assign
> permissions to groups (this worked before via authzgroups plugin)
> should have been a BLOCKER for 0.12.

This has been the case forever, and nobody has stepped up to provide a
fix. So if it hasn't been a blocker for previous releases, it wasn't for
0.12 either.

> Maybe I've just done the configuration wrong and all the above items
> can be handled (in that case I'm eager to learn how ;) ).

Not all, but some of it :)

-- Remy

signature.asc

HeX

unread,
Aug 3, 2010, 9:11:29 AM8/3/10
to Trac Development
Hi Remy,

sorry for the late reply...holidays...
On 20 Jul, 17:19, Remy Blank <remy.bl...@pobox.com> wrote:
> > 3.) The worst thing is that Trac will obey non of the svn permissions
> > given by the authz file that controls the svn access. Anybody with
> > BROWSER_VIEW will now be able to browse the WHOLE source tree
> > regardless what the svn auhtz defines. In my case I had to take away
> > BROWSER_VIEW from all anonymous users (very irritating) just I have
> > some private folders in the repo.
>
> That's surprising. Did you set "[trac] authz_file" and "[trac]
> autz_module_name" correctly in trac.ini? Do you use multiple
> repositories? Are your repositories named the same in Trac and in the
> authz file?

My trac.ini states:
---8<---
[trac]
authz_file = /home/svn/
svn_authz
authz_module_name = projects
---8<---

and svn_authz looks like this:

---8<---
[projects:/]
* =
@observers = r
@webdevs = rw

#### foo ####
[projects:/foo]
* = r

#### bar ####
[projects:/bar]
* =
@observers = r
---8<---

But anonymous user with BROWSER_VIEW will be able to browse "projects:/
bar" none the less. :(

I can't really see an error in that configuration (and also this
configuration worked under 0.11.x fine)

Thanks again,
HeX

Remy Blank

unread,
Aug 3, 2010, 10:16:15 AM8/3/10
to trac...@googlegroups.com
HeX wrote:
> But anonymous user with BROWSER_VIEW will be able to browse "projects:/
> bar" none the less. :(

Of course, if you give anonymous BROWSER_VIEW, he will be able to browse
files :)

You should remove BROWSER_VIEW (and also CHANGESET_VIEW, FILE_VIEW and
LOG_VIEW) from all users (including anonymous), as that overrides the
fine-grained permissions. The permissions are now granted by the authz
system directly.

This indeed seems to be a difference in behavior from 0.11. We should
probably document that. Actually, TracFineGrainedPermissions still
mentions the old system, so we should rewrite the whole section.

-- Remy

signature.asc

HeX

unread,
Aug 3, 2010, 10:34:55 AM8/3/10
to Trac Development
> This indeed seems to be a difference in behavior from 0.11. We should
> probably document that. Actually, TracFineGrainedPermissions still
> mentions the old system, so we should rewrite the whole section.

Indeed and this is where my security concern comes from since it was
not doumented and I only discovered it by accident.

So I will add
[projects:/foo]
anonymous = BROWSER_VIEW,CHANGESET_VIEW,LOG_VIEW

in order that "normal" people can have a look at the public part
again. Thanks for the hint :)

/HeX

Remy Blank

unread,
Aug 3, 2010, 10:57:49 AM8/3/10
to trac...@googlegroups.com
HeX wrote:
> So I will add
> [projects:/foo]
> anonymous = BROWSER_VIEW,CHANGESET_VIEW,LOG_VIEW

That would be:

[projects:/foo]
anonymous = r

-- Remy

signature.asc

HeX

unread,
Aug 3, 2010, 11:08:19 AM8/3/10
to Trac Development
Remy,

I'm talking about the authz file used by trac to handle fine-grained
permissions not the svn authz file. The latter 0.12 no longer cares
about (if I understood you correctly).
Or how will
> [projects:/foo]
> anonymous = r
tell Trac that anonymous has now BROWSER_VIEW etc.?

I'm afraid that I'm still not very confident with the new way 0.12
handles fine grained permissions.

/HeX

Remy Blank

unread,
Aug 3, 2010, 12:26:33 PM8/3/10
to trac...@googlegroups.com
HeX wrote:
> I'm talking about the authz file used by trac to handle fine-grained
> permissions not the svn authz file. The latter 0.12 no longer cares
> about (if I understood you correctly).

In fact, the SVN authz file will now give BROWSER_VIEW, FILE_VIEW,
CHANGESET_VIEW and LOG_VIEW based on the paths you configure. For
example, if you have:

[projects:/foo]
anonymous = r

Then anonymous will get BROWSER_VIEW and FILE_VIEW for all paths below
/foo. Also, it will get CHANGESET_VIEW and LOG_VIEW for all changesets
that contain at least one path below /foo, and when displaying those
changesets, it will only show the files below /foo

This should not be confused with the authz_policy.py permission policy,
which allows managing permissions to any Trac resource like wiki pages
and tickets. It has a configuration with similar syntax, but the analogy
more or less stops here.

So in your case: don't specify any of BROWSER_VIEW, FILE_VIEW,
CHANGESET_VIEW and LOG_VIEW in the "global" permissions ("trac-admin
permission" or the "Permissions" admin panel), configure your SVN authz
file to restrict access to SVN, and pass the file to Trac in [trac]
authz_file. Trac will then enforce the same restrictions as SVN.

Note that the names of your repositories must be the same in SVN and in
Trac.

-- Remy

signature.asc

HeX

unread,
Aug 4, 2010, 3:59:58 AM8/4/10
to Trac Development
Remy,

On 3 Aug, 18:26, Remy Blank <remy.bl...@pobox.com> wrote:
> So in your case: don't specify any of BROWSER_VIEW, FILE_VIEW,
> CHANGESET_VIEW and LOG_VIEW in the "global" permissions ("trac-admin
> permission" or the "Permissions" admin panel), configure your SVN authz
> file to restrict access to SVN, and pass the file to Trac in [trac]
> authz_file. Trac will then enforce the same restrictions as SVN.

This is exactly the setup I have and what I'm on about because exactly
THIS DOES NOT WORK in 0.12 any more.
Before you could specify BROWSER_VIEW, etc in the global permissions
and then Trac would look into the authz_file to check which
directories the user can enter/view. Now giving any group
BROWSER_VIEW, etc., in the global permissions will give the respective
group *global* BROWSER_VIEW no matter what the authz_file states.

On the other hand, denying, e.g., anonymous, BROWSER_VIEW will lead to
anonymous not being able to browse the source AT ALL. No matter what
authz_file says (the authz_file is, again, simply ignored by Trac
0.12) Trac wouldn't know that anonymous users should get the "Browse
Source" button or be able to access foo/Browser.

Do you see where the problem is?
/HeX

Christian Boos

unread,
Aug 4, 2010, 4:19:45 AM8/4/10
to trac...@googlegroups.com

Isn't that simply a problem with the ordering of policies?
What is your "[trac] permission_policies" setting?
Does it help to put AuthzSourcePolicy first?

-- Christian

Remy Blank

unread,
Aug 4, 2010, 4:36:29 AM8/4/10
to trac...@googlegroups.com
HeX wrote:
> This is exactly the setup I have and what I'm on about because exactly
> THIS DOES NOT WORK in 0.12 any more.

Really?

> On the other hand, denying, e.g., anonymous, BROWSER_VIEW will lead to
> anonymous not being able to browse the source AT ALL. No matter what
> authz_file says (the authz_file is, again, simply ignored by Trac
> 0.12) Trac wouldn't know that anonymous users should get the "Browse
> Source" button or be able to access foo/Browser.

Well, I have this exact setup here, and it's been working fine for
weeks. Did you add AuthzSourcePolicy to [trac] permission_policies, as
instructed in... well, nowhere, actually, not even the API changes
document. Let me fix that...

Here you go:

http://trac.edgewall.org/wiki/TracUpgrade#Auhtzpermissionchecking

Oh, actually, it's hidden in the help text for [trac] authz_file, but
that's probably not acceptable :)

-- Remy

signature.asc

HeX

unread,
Aug 4, 2010, 4:38:21 AM8/4/10
to Trac Development
Christian your input finally solved it

However not as you intended. The problem was/is that the *name* of the
permission policy was changed from "AuthzPolicy" to
"AuthSourcePolicy". No wonder that that users now have global Browse
permissions since svn_authz.py was never triggered. Such a name change
should be marked in BIG RED LETTERS in the release notes since there
should be lots of system not being aware of this change and suddenly
opening up ALL their protected repos for browsing.

Also I could only find the mention of AuthzSourcePolicy here
http://trac.edgewall.org/wiki/TracDev/ApiChanges/0.12#Authz and there
is no (obvious) mention that this used to be AuthzPolicy as such.
Maybe this could be improved :)

@Remy, so in the end one needs to give the user BROWSER_VIEW, etc. in
order to be able to browse the source. This can not be done (yet?) via
FineGrainedPermissions

Thanks again for the help,
/HeX
Message has been deleted

HeX

unread,
Aug 4, 2010, 4:48:42 AM8/4/10
to Trac Development
Remy,

Ok we kind of wrote at the same time here. Thanks for updating the
documentation 2 last things:

* Following your advice given in
http://trac.edgewall.org/wiki/TracUpgrade#Auhtzpermissionchecking
will remove the "Browse Source" button for anonymous users. Making it
a bit hard to find the source ;)

* Can you confirm that AuthzPolicy is obsoleted by AuthzSourcePolicy
and therefore can be removed from permission_policies completely?

/HeX
>  signature.asc
> < 1 KVisLast ned

Remy Blank

unread,
Aug 4, 2010, 4:57:45 AM8/4/10
to trac...@googlegroups.com
HeX wrote:
> * Following your advice given in
> http://trac.edgewall.org/wiki/TracUpgrade#Auhtzpermissionchecking
> will remove the "Browse Source" button for anonymous users. Making it
> a bit hard to find the source ;)

No, should be able to control access to the source for anonymous in your
authz file, like any other user.

> * Can you confirm that AuthzPolicy is obsoleted by AuthzSourcePolicy
> and therefore can be removed from permission_policies completely?

No, AuthzPolicy and AuthzSourcePolicy are two different things. The
former allows controlling access to any Trac resource (wiki, tickets,
...), while the other one allows enforcing the same access rules to the
repositories in Trac as you have in Subversion, by using the same authz
file.

-- Remy

signature.asc

HeX

unread,
Aug 4, 2010, 5:12:07 AM8/4/10
to Trac Development
On 4 Aug, 10:57, Remy Blank <remy.bl...@pobox.com> wrote:
> HeX wrote:
> >  * Following your advice given in
> >http://trac.edgewall.org/wiki/TracUpgrade#Auhtzpermissionchecking
> > will remove the "Browse Source" button for anonymous users. Making it
> > a bit hard to find the source ;)
>
> No, should be able to control access to the source for anonymous in your
> authz file, like any other user.

I guess then there is a bug. I've now removed the global permissions
as suggested in
http://trac.edgewall.org/wiki/TracUpgrade#Auhtzpermissionchecking with
the result that anonymous users will NOT see the "Browse Source"
button but authenticated will. Mind if I enter the correct browse URL
as anonymous I will be able to access the non restricted part of the
repo. So AuthzSourcePolicy works but just does not unhide the "Browse
Source" button for anonymous users.

If you agree I can file this as a bug.

> >  * Can you confirm that AuthzPolicy is obsoleted by AuthzSourcePolicy
> > and therefore can be removed from permission_policies completely?
>
> No, AuthzPolicy and AuthzSourcePolicy are two different things. The
> former allows controlling access to any Trac resource (wiki, tickets,
> ...), while the other one allows enforcing the same access rules to the
> repositories in Trac as you have in Subversion, by using the same authz
> file.

OK now I finally got it (I think). Actually it was
http://trac.edgewall.org/wiki/TracFineGrainedPermissions#mod_authz_svn-likepermissionpolicy
that was confusing me and should probably be rewritten with the
information from http://trac.edgewall.org/wiki/TracUpgrade#Auhtzpermissionchecking
also to make the difference of AuthzPolicy and AuthzSourcePolicy more
clear.

/HeX

Christian Boos

unread,
Aug 4, 2010, 5:25:57 AM8/4/10
to trac...@googlegroups.com
On 8/4/2010 11:12 AM, HeX wrote:
> On 4 Aug, 10:57, Remy Blank<remy.bl...@pobox.com> wrote:
>
>> HeX wrote:
>>
>>> * Following your advice given in
>>> http://trac.edgewall.org/wiki/TracUpgrade#Auhtzpermissionchecking
>>> will remove the "Browse Source" button for anonymous users. Making it
>>> a bit hard to find the source ;)
>>>
>> No, should be able to control access to the source for anonymous in your
>> authz file, like any other user.
>>
> I guess then there is a bug. I've now removed the global permissions
> as suggested in
> http://trac.edgewall.org/wiki/TracUpgrade#Auhtzpermissionchecking with
> the result that anonymous users will NOT see the "Browse Source"
> button but authenticated will. Mind if I enter the correct browse URL
> as anonymous I will be able to access the non restricted part of the
> repo. So AuthzSourcePolicy works but just does not unhide the "Browse
> Source" button for anonymous users.
>
> If you agree I can file this as a bug.
>

If you use the AuthzSourcePolicy *first*(well, SvnAuthzSourcePolicy
would probably have been a less confusing name - even if there's no
source dependency to svn, the permission model it implements is the one
of svn), *then* give BROWSER_VIEW to anonymous with the default,
coarse-grained permission, then the Browse Repository button should be
visible... yet the access to non-authorized parts of the repositories
should still be properly denied (untested though, but that's how it
should work).

-- Christian

HeX

unread,
Aug 4, 2010, 5:34:15 AM8/4/10
to Trac Development
On 4 Aug, 11:25, Christian Boos <cb...@neuf.fr> wrote:
> If you use the AuthzSourcePolicy *first*(well, SvnAuthzSourcePolicy
> would probably have been a less confusing name - even if there's no
> source dependency to svn, the permission model it implements is the one
> of svn), *then* give BROWSER_VIEW to anonymous with the default,
> coarse-grained permission, then the Browse Repository button should be
> visible... yet the access to non-authorized parts of the repositories
> should still be properly denied (untested though, but that's how it
> should work).

Unfortunately it does not work this way. I tried it before and also
again just now. The "Browse Source" button stays hidden. Also this
does not explain why the button appears for authenticated users (who
neither have BROWSER_VIEW permission in the "coarse-grained"
permission settings).

/HeX

Remy Blank

unread,
Aug 4, 2010, 7:00:57 AM8/4/10
to trac...@googlegroups.com
HeX wrote:
> If you agree I can file this as a bug.

Yes, please open a ticket, it will serve as a reminder for me to check
the case of anonymous users. I remember checking all possible cases for
authenticated users, but I'm not sure anymore about anonymous.

Are you using "anonymous" in your authz file to set permissions for
anonymous, or "$anonymous"? The latter isn't supported yet, see:

http://trac.edgewall.org/ticket/8289.

-- Remy

signature.asc

HeX

unread,
Aug 4, 2010, 7:15:00 AM8/4/10
to Trac Development
On 4 Aug, 13:00, Remy Blank <remy.bl...@pobox.com> wrote:
> HeX wrote:
> > If you agree I can file this as a bug.
>
> Yes, please open a ticket, it will serve as a reminder for me to check
> the case of anonymous users. I remember checking all possible cases for
> authenticated users, but I'm not sure anymore about anonymous.

OK filed under http://trac.edgewall.org/ticket/9542

> Are you using "anonymous" in your authz file to set permissions for
> anonymous, or "$anonymous"? The latter isn't supported yet, see:
I'm still using "anonymous" (didn't actually know about $anonymous
until you mentioned it just now)
Reply all
Reply to author
Forward
0 new messages