Ticket #8445 (closed defect: fixed)
Opened 3 years ago
Last modified 2 years ago
authz_policy receives 'None' as resource
| Reported by: | funsheep@… | Owned by: | rblank |
|---|---|---|---|
| Priority: | normal | Milestone: | 0.12 |
| Component: | general | Version: | 0.11.5 |
| Severity: | normal | Keywords: | authzpolicy verify |
| Cc: | admin@… | ||
| Release Notes: | |||
| API Changes: | |||
Description (last modified by cboos) (diff)
I'm running a trac 0.11.4 system on an apache2 server. I wanted to have the permissions checked by the AuthzPolicy. I have
- added the authz_policy field to the trac.ini and a correct path to an authz.conf file
- i have enabled the plugin (and for testing purposes disabled all other plugins)
- i have set permission_policies = AuthzPolicy
- authz_policy.py loaded from authz_policy.py - as stated on the website
- The trac installation is a fresh one, without editing anything. Trac was installed with easy_install
- The environment is also a fresh one
- There is a global trac.ini defining the standard permission_policies among other things
- And there is a environment specific trac.ini overwriting some of the definitions
My authz.conf looks like:
# vim: syntax=dosini [groups] administrator = me developer = dev1, dev2, dev3 # Match everything else [*] @administrator = TRAC_ADMIN anonymous = BLOG_VIEW, BROWSER_VIEW, CHANGESET_VIEW, FILE_VIEW, LOG_VIEW, MILESTONE_VIEW, REPORT_SQL_VIEW, REPORT_VIEW, ROADMAP_VIEW, SEARCH_VIEW, TICKET_VIEW, TIMELINE_VIEW, WIKI_VIEW authenticated = POLL_VOTE, TICKET_APPEND, TICKET_CREATE @developer = BLOG_CREATE, BLOG_MODIFY_OWN, WIKI_CREATE, WIKI_DELETE, WIKI_MODIFY, XML_RPC
After reloading the apache i'm not able to see anything but the wiki (blog plugin is disabled).
After checking the log, i found this entry
2009-07-03 12:50:00,462 Trac[authz_policy] DEBUG: Checking REPORT_VIEW on
I then added some more debug-lines to the .py file and found this
self.log.debug('Checking %s on %s (unnormalized)', action, resource)
gives
2009-07-03 12:50:00,461 Trac[authz_policy] DEBUG: Checking SEARCH_VIEW on None (unnormalized)
And fnmatch between '' and '*@*' (resource_glob) in line 216 returns false.
Some of the permission checks work (therefore i know that the setup is ok). From the log
2009-07-03 12:50:00,458 Trac[authz_policy] DEBUG: Checking WIKI_VIEW on <Resource 'wiki'> (unnormalized) 2009-07-03 12:50:00,458 Trac[authz_policy] DEBUG: Checking WIKI_VIEW on wiki:*@* 2009-07-03 12:50:00,459 Trac[authz_policy] DEBUG: Resource glob *@* 2009-07-03 12:50:00,459 Trac[authz_policy] DEBUG: fnmatch gives: True 2009-07-03 12:50:00,459 Trac[authz_policy] DEBUG: wiki:*@* matched section *@* for user funsheep
Attachments
Change History
comment:1 Changed 3 years ago by cboos
- Description modified (diff)
- Keywords authzpolicy verify added
- Summary changed from authz_policy recieves 'None' as recource to authz_policy receives 'None' as resource
comment:2 Changed 3 years ago by cboos
- Keywords needinfo added
comment:3 Changed 3 years ago by anonymous
anonymous does already have the TICKET_VIEW permission (according to the policy file).
To me it seems that the authz_policy.py does not correctly handle the case of the 'None' resource.
comment:4 Changed 3 years ago by anonymous
I have now verified that this problem also exists with trac v0.11.5. (Just installed it).
comment:5 Changed 2 years ago by cboos
- Keywords needinfo removed
- Milestone set to 0.12
- Owner set to cboos
comment:6 Changed 2 years ago by cboos
- Milestone 0.12 deleted
- Resolution set to worksforme
- Status changed from new to closed
Works for me now. Probably r8786 also helped here, as anonymous is also listed before authenticated in the provided authzpolicy.conf.
No issue with None seen either.
comment:7 Changed 2 years ago by admin@…
- Resolution worksforme deleted
- Status changed from closed to reopened
- Version changed from 0.11.4 to 0.11.5
I've just encountered this problem on trac 0.11.6 RC1 my authz.conf file contained simply the following
[*] * = TRAC_ADMIN
Which should grant everyone TRAC_ADMIN
It threw up the following errors
2009-11-24 11:31:20,917 Trac[authz_policy] DEBUG: Checking TICKET_CREATE on 2009-11-24 11:31:20,917 Trac[perm] DEBUG: No policy allowed anonymous performing TICKET_CREATE on None
(That's just a sample the log was pretty long)
The problem seems to be because the resource_ket in authz_policy.py is an empty string so doesn't match anything in authz.conf file.
I added the following to the file under authz_permissions
if resource_key == '':
resource_key = '*@*'
self.env.log.debug('Empty resource_key')
comment:9 follow-up: ↓ 10 Changed 2 years ago by rblank
OT: Weird, the patch above seems to be rendered with Enscript in the preview...
comment:10 in reply to: ↑ 9 Changed 2 years ago by cboos
- Milestone set to 0.12
- Status changed from reopened to new
Replying to rblank:
OT: Weird, the patch above seems to be rendered with Enscript in the preview...
It's not an unified diff, but a context diff.
I'll verify the issue.
Changed 2 years ago by rblank
- Attachment 8445-resource-key-r9250.patch added
Fix key for empty resources.
comment:11 Changed 2 years ago by rblank
The patch above has the same effect, but feels slightly less hackish. OTOH, looking at auth_policy.py, I feel there is much to be improved there, both in terms of correctness and performance.
Review appreciated.
comment:12 follow-up: ↓ 13 Changed 2 years ago by cboos
Patch looks good (but the second chunk is not needed, is it?)
comment:13 in reply to: ↑ 12 ; follow-up: ↓ 14 Changed 2 years ago by rblank
Replying to cboos:
(but the second chunk is not needed, is it?)
It's not needed to solve this issue, but I feel it reads better. Also, it avoids creating two lists in the "authenticated" case.
comment:14 in reply to: ↑ 13 Changed 2 years ago by cboos
Replying to rblank:
Also, it avoids creating two lists in the "authenticated" case.
Ah yes, my criterion so far has been to avoid one unnecessary line, but this sure beats it ;-)
comment:15 Changed 2 years ago by rblank
- Resolution set to fixed
- Status changed from new to closed
Patch applied in [9345].
comment:16 Changed 2 years ago by rblank
- Owner changed from cboos to rblank



Normally checking against "None" means "is the permission granted in general", so this shouldn't be problematic.
What happens if you add the TICKET_VIEW in the permissions?