Edgewall Software
Modify

Opened 7 years ago

Closed 5 years ago

Last modified 4 years ago

#6680 closed defect (fixed)

The authz_policy.py sample is only a *sample*

Reported by: alristico@… Owned by: cboos
Priority: normal Milestone: 0.12
Component: admin/console Version: 0.11b1
Severity: normal Keywords: authzpolicy TracPermissions TracFineGrainedPermissions perdirectory
Cc: conny@…, leho@…
Release Notes:
API Changes:

Description

I had some trouble with setting up a policy where the anonymous user could see only the front page of the wiki (wiki/WikiStart), but not the rest of the wiki without further authorisation through logging in. I used the authz_policy.py and had the following in the associated authz file:

[groups]
superdevs = me

[wiki:WikiStart]
anonymous = WIKI_VIEW

[wiki:*]
anonymous =

[*]
@superdevs = TRAC_ADMIN
anonymous = MILESTONE_VIEW, ROADMAP_VIEW, TIMELINE_VIEW

According to the docs in the authz_policy.py file, order of the directives mattered. The first directive should have allowed anonymous visitors access to the front page, while the second directive dissallowed anonymous browsing of the rest of the wiki. Instead, this resulted in an error:

No handler matched request to /wiki/WikiStart

I talked to "aat" on the IRC channel and he came up with the following:

the issue is that trac checks for access to AT LEAST ONE resource
in a realm by just checking if the user has the permission on <realm>

"aat" also provided a patch and stated that he would try and come up with something better soon.

Everyone seems to agree that someone should create a trac hack out of this. Anyone out there have copious amounts of free time for that?

Attachments (2)

authz_policy.patch (602 bytes) - added by alristico@… 7 years ago.
Temporary patch file for authz_policy.py
authz_policy.2.patch (1.7 KB) - added by Dustin Spicuzza <dustin@…> 6 years ago.
Allows nested groups in authz group specification

Download all attachments as: .zip

Change History (16)

Changed 7 years ago by alristico@…

Temporary patch file for authz_policy.py

comment:1 Changed 7 years ago by athomas

  • Owner changed from cmlenz to athomas
  • Status changed from new to assigned

comment:2 Changed 7 years ago by anonymous

Darn, I just ran in to the same issue.. or similar. In my authpolicy.conf:

# view and edit a specific page
[wiki:DK]
betti = WIKI_VIEW, WIKI_MODIFY, WIKI_CREATE, WIKI_DELETE

# allowed to see the default page where a link to the editable page can be presented
[wiki:WikiStart]
betti = WIKI_VIEW

other pages and modules should get permissions "None", so nothing extraneous will be displayed.

But from here on things are quite inconsequent:

/
The WikiStart page is displayed and so is the link to the [wiki:DK] page. Fine!
/wiki/DK
Error: Not Found No handler matched request to /wiki/DK
/wiki/WikiStart
Error: Not Found No handler matched request to /wiki/WikiStart
/wiki
Error: Not Found No handler matched request to /wiki

It seem as if, to be able to display any URL starting with /wiki* (i.e. everything other than just "/") the wiki module thinks that you need WIKI_VIEW on [wiki:*@*]…which would kind of beat the purpose here.

comment:3 Changed 7 years ago by conny@…

anonymous forgot to fill in my email ;-)

comment:4 Changed 7 years ago by cboos

  • Priority changed from low to normal

The Error: Not Found No handler matched request to /wiki comes from the fact that the view permission is not granted for the whole Wiki realm. The authz_policy plugin should actually return True for this check, as soon as it knowns that at least one Wiki page is reachable. Otherwise, it should return None, leaving the possibility to other plugins to decide, or even False, if the authz_policy knowns that no Wiki page can be viewed.

See also #6211, which contains a discussion very relevant to the specific problem raised here, and r6188 which shows what a permission plugin is supposed to do in this case.

comment:5 follow-up: Changed 7 years ago by digiqr+trac@…

I have little question about authz_policy.py. Is it possible that authz_policy.py will use "groups" from Trac permissions? I have few groups like:

member1 _role1
member2 _role2
member3 _admin
_role2 _role1
_role1 some trac rights
_role2 additional rights
_admin TRAC_ADMIN

I can't use _role1, _role2 or _admin in authz file, just only memberx. I must recreate groups in [groups] section, but is is uncomfortable.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 7 years ago by osimons

Replying to digiqr+trac@gmail.com:

I have little question about authz_policy.py. Is it possible that authz_policy.py will use "groups" from Trac permissions?

No, it isn't. The main problem is that the groups gets expanded into the individual permissions, but there is no API for checking the groups (roles) of users or permissions against it. A number of tickets deals with improvements to the user APIs - notably #5648, #5425, and #2456. Scheduled for 0.12, so hopefully by then…

comment:7 Changed 7 years ago by conny@…

  • Cc conny@… added

For now, I could do without groups all in all - could only the sample AuthzPolicy do what it is supposed to do at least for users ;-)

comment:8 Changed 6 years ago by Dustin Spicuzza <dustin@…>

Another problem with the authz_policy.py is that it does not support nesting groups within groups in the file specification, whereas SVN's authz does. I'm attaching a patch that fixes this.

Changed 6 years ago by Dustin Spicuzza <dustin@…>

Allows nested groups in authz group specification

comment:9 in reply to: ↑ 6 Changed 6 years ago by gw.trac@…

Replying to osimons:

Replying to digiqr+trac@..:

I have little question about authz_policy.py. Is it possible that authz_policy.py will use "groups" from Trac permissions?

No, it isn't. The main problem is that the groups gets expanded into the individual permissions, but there is no API for checking the groups (roles) of users or permissions against it. A number of tickets deals with improvements to the user APIs - notably #5648, #5425, and #2456. Scheduled for 0.12, so hopefully by then…

Hm, a dirty workaround patch is in #7650 that Dustin just closed as duplicate of this. Actually it is exactly what digiqr wanted to have realized with the currently available API. It is not elegant and slow (you probably won't notice), but it works.

comment:10 Changed 6 years ago by cboos

  • Milestone changed from 0.11.2 to 0.11.3

comment:11 Changed 5 years ago by cboos

  • Keywords authzpolicy added; authz removed

comment:12 Changed 5 years ago by cboos

  • Milestone changed from next-minor-0.12.x to 0.12
  • Resolution set to fixed
  • Status changed from assigned to closed

anonymous permission definitions were also matching for authenticated users.

So in the example reported here, when checking the permission for a wiki page, the following:

[wiki:*]
anonymous =

was matching for the "me" user and the next setting:

[*]
@superdevs = TRAC_ADMIN

was simply not seen.

Fixed in [8786].

comment:13 Changed 5 years ago by cboos

  • Owner changed from athomas to cboos

comment:14 Changed 4 years ago by lkraav <leho@…>

  • Cc leho@… added

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain cboos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from cboos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.