| 31 | | |
| 32 | | - Install [http://www.voidspace.org.uk/python/configobj.html ConfigObj] (required). |
| 33 | | - Copy authz_policy.py into your plugins directory. |
| 34 | | - Put a [http://swapoff.org/files/authzpolicy.conf authzpolicy.conf] file somewhere, preferably on a secured location on the server, not readable for others than the webuser. If the file contains non-ASCII characters, the UTF-8 encoding should be used. |
| 35 | | - Update your `trac.ini`: |
| 36 | | 1. modify the [TracIni#trac-section permission_policies] entry in the `[trac]` section |
| | 32 | ==== Configuration ==== |
| | 33 | * Install [http://www.voidspace.org.uk/python/configobj.html ConfigObj] (still needed for 0.12 and later). |
| | 34 | * Copy [browser:/trunk/tracopt/perm/authz_policy.py /tracopt/perm/authz_policy.py] to your environment's plugins directory (only for Trac 0.11). |
| | 35 | * Put a [http://swapoff.org/files/authzpolicy.conf authzpolicy.conf] file somewhere, preferably on a secured location on the server, not readable for others than the webuser. If the file contains non-ASCII characters, the UTF-8 encoding should be used. |
| | 36 | * Update your `trac.ini`: |
| | 37 | 1. modify the [TracIni#trac-section permission_policies] entry in the `[trac]` section |
| 60 | | A policy will return either `True`, `False` or `None` for a given permission check. |
| 61 | | Only if the return value is `None` will the ''next'' permission policy be consulted. |
| 62 | | If no policy explicitly grants the permission, the final result will be `False` |
| 63 | | (i.e. no permission). |
| | 63 | A policy will return either `True`, `False` or `None` for a given permission check. `True` is returned if the policy explicitly grants the permission. `False` is returned if the policy explicitly denies the permission. `None` is returned if the policy is unable to either grant or deny the permission. |
| | 64 | |
| | 65 | NOTE: Only if the return value is `None` will the ''next'' permission policy be consulted. |
| | 66 | If none of the policies explicitly grants the permission, the final result will be `False` |
| | 67 | (i.e. permission denied). |
| | 68 | |
| | 69 | The `authzpolicy.conf` file is a `.ini` style configuration file: |
| | 70 | {{{ |
| | 71 | [wiki:PrivatePage@*] |
| | 72 | john = WIKI_VIEW, !WIKI_MODIFY |
| | 73 | jack = WIKI_VIEW |
| | 74 | * = |
| | 75 | }}} |
| | 76 | * Each section of the config is a glob pattern used to match against a Trac resource |
| | 77 | descriptor. These descriptors are in the form: |
| | 78 | {{{ |
| | 79 | <realm>:<id>@<version>[/<realm>:<id>@<version> ...] |
| | 80 | }}} |
| | 81 | Resources are ordered left to right, from parent to child. If any |
| | 82 | component is inapplicable, `*` is substituted. If the version pattern is |
| | 83 | not specified explicitely, all versions (`@*`) is added implicitly |
| | 84 | |
| | 85 | Example: Match the WikiStart page |
| | 86 | {{{ |
| | 87 | [wiki:*] |
| | 88 | [wiki:WikiStart*] |
| | 89 | [wiki:WikiStart@*] |
| | 90 | [wiki:WikiStart] |
| | 91 | }}} |
| | 92 | |
| | 93 | Example: Match the attachment `wiki:WikiStart@117/attachment:FOO.JPG@*` |
| | 94 | on WikiStart |
| | 95 | {{{ |
| | 96 | [wiki:*] |
| | 97 | [wiki:WikiStart*] |
| | 98 | [wiki:WikiStart@*] |
| | 99 | [wiki:WikiStart@*/attachment:*] |
| | 100 | [wiki:WikiStart@117/attachment:FOO.JPG] |
| | 101 | }}} |
| | 102 | |
| | 103 | * Sections are checked against the current Trac resource descriptor '''IN ORDER''' of |
| | 104 | appearance in the configuration file. '''ORDER IS CRITICAL'''. |
| | 105 | |
| | 106 | * Once a section matches, the current username is matched against the keys |
| | 107 | (usernames) of the section, '''IN ORDER'''. |
| | 108 | * If a key (username) is prefixed with a `@`, it is treated as a group. |
| | 109 | * If a value (permission) is prefixed with a `!`, the permission is |
| | 110 | denied rather than granted. |
| | 111 | |
| | 112 | The username will match any of 'anonymous', 'authenticated', <username> or '*', using normal Trac permission rules. || '''Note:''' Other groups which are created by user (e.g. by 'adding subjects to groups' on web interface page //Admin / Permissions//) cannot be used. See [trac:ticket:5648 #5648] for details about this missing feature || |
| 82 | | - All versions of WikiStart will be viewable by everybody (including anonymous) |
| 83 | | - !PrivatePage will be viewable only by john |
| 84 | | - other pages will be viewable only by john and jack |
| 85 | | |
| | 131 | * All versions of WikiStart will be viewable by everybody (including anonymous) |
| | 132 | * !PrivatePage will be viewable only by john |
| | 133 | * other pages will be viewable only by john and jack |
| | 134 | |
| | 135 | Groups: |
| | 136 | {{{ |
| | 137 | [groups] |
| | 138 | admins = john, jack |
| | 139 | devs = alice, bob |
| | 140 | |
| | 141 | [wiki:Dev@*] |
| | 142 | @admins = TRAC_ADMIN |
| | 143 | @devs = WIKI_VIEW |
| | 144 | * = |
| | 145 | |
| | 146 | [*] |
| | 147 | @admins = TRAC_ADMIN |
| | 148 | * = |
| | 149 | }}} |
| | 150 | |
| | 151 | Then: |
| | 152 | - everything is blocked (whitelist approach), but |
| | 153 | - admins get all TRAC_ADMIN everywhere and |
| | 154 | - devs can view wiki pages. |
| | 155 | |
| | 156 | Some repository examples (Browse Source specific): |
| | 157 | {{{ |
| | 158 | # A single repository: |
| | 159 | [repository:test_repo@*] |
| | 160 | john = BROWSER_VIEW, FILE_VIEW |
| | 161 | # John has BROWSER_VIEW and FILE_VIEW for the entire test_repo |
| | 162 | |
| | 163 | # The default repository (requires Trac 1.0.2 or later): |
| | 164 | [repository:@*] |
| | 165 | john = BROWSER_VIEW, FILE_VIEW |
| | 166 | # John has BROWSER_VIEW and FILE_VIEW for the entire default repository |
| | 167 | |
| | 168 | # All repositories: |
| | 169 | [repository:*@*] |
| | 170 | jack = BROWSER_VIEW, FILE_VIEW |
| | 171 | # Jack has BROWSER_VIEW and FILE_VIEW for all repositories |
| | 172 | }}} |
| | 173 | |
| | 174 | Very fine grain repository access: |
| | 175 | {{{ |
| | 176 | # John has BROWSER_VIEW and FILE_VIEW access to trunk/src/some/location/ only |
| | 177 | [repository:test_repo@*/source:trunk/src/some/location/*@*] |
| | 178 | john = BROWSER_VIEW, FILE_VIEW |
| | 179 | |
| | 180 | |
| | 181 | # John has BROWSER_VIEW and FILE_VIEW access to only revision 1 of all files at trunk/src/some/location only |
| | 182 | [repository:test_repo@*/source:trunk/src/some/location/*@1] |
| | 183 | john = BROWSER_VIEW, FILE_VIEW |
| | 184 | |
| | 185 | |
| | 186 | # John has BROWSER_VIEW and FILE_VIEW access to all revisions of 'somefile' at trunk/src/some/location only |
| | 187 | [repository:test_repo@*/source:trunk/src/some/location/somefile@*] |
| | 188 | john = BROWSER_VIEW, FILE_VIEW |
| | 189 | |
| | 190 | |
| | 191 | # John has BROWSER_VIEW and FILE_VIEW access to only revision 1 of 'somefile' at trunk/src/some/location only |
| | 192 | [repository:test_repo@*/source:trunk/src/some/location/somefile@1] |
| | 193 | john = BROWSER_VIEW, FILE_VIEW |
| | 194 | }}} |
| | 195 | |
| | 196 | Note: In order for Timeline to work/visible for John, we must add CHANGESET_VIEW to the above permission list. |
| | 197 | |
| | 198 | |
| | 199 | ==== Missing Features ==== |
| | 200 | Although possible with the !DefaultPermissionPolicy handling (see Admin panel), fine-grained permissions still miss those grouping features (see [trac:ticket:9573 #9573], [trac:ticket:5648 #5648]). Patches are partially available, see forgotten authz_policy.2.patch part of [trac:ticket:6680 #6680]). |
| | 201 | |
| | 202 | You cannot do the following: |
| | 203 | {{{ |
| | 204 | [groups] |
| | 205 | team1 = a, b, c |
| | 206 | team2 = d, e, f |
| | 207 | team3 = g, h, i |
| | 208 | departmentA = team1, team2 |
| | 209 | }}} |
| | 210 | |
| | 211 | Permission groups are not supported either. You cannot do the following: |
| | 212 | {{{ |
| | 213 | [groups] |
| | 214 | permission_level_1 = WIKI_VIEW, TICKET_VIEW |
| | 215 | permission_level_2 = permission_level_1, WIKI_MODIFY, TICKET_MODIFY |
| | 216 | [*] |
| | 217 | @team1 = permission_level_1 |
| | 218 | @team2 = permission_level_2 |
| | 219 | @team3 = permission_level_2, TICKET_CREATE |
| | 220 | }}} |
| | 296 | |
| | 297 | === ReadonlyWikiPolicy |
| | 298 | |
| | 299 | Since 1.1.2, the read-only attribute of wiki pages is enabled and enforced when `ReadonlyWikiPolicy` is in the list of active permission policies. The default for new Trac installations in 1.1.2 and later is: |
| | 300 | {{{ |
| | 301 | [trac] |
| | 302 | permission_policies = ReadonlyWikiPolicy, |
| | 303 | DefaultPermissionPolicy, |
| | 304 | LegacyAttachmentPolicy |
| | 305 | }}} |
| | 306 | |
| | 307 | When upgrading from earlier versions of Trac, `ReadonlyWikiPolicy` will be appended to the list of `permission_policies` when upgrading the environment, provided that `permission_policies` has the default value. If any non-default `permission_polices` are active, `ReadonlyWikiPolicy` **will need to be manually added** to the list. A message will be echoed to the console when upgrading the environment, indicating if any action needs to be taken. |
| | 308 | |
| | 309 | **!ReadonlyWikiPolicy must be listed //before// !DefaultPermissionPolicy**. The latter returns `True` to allow modify, delete or rename actions when the user has the respective `WIKI_*` permission, without consideration for the read-only attribute. |
| | 310 | |
| | 311 | The `ReadonlyWikiPolicy` returns `False` to deny modify, delete and rename actions on wiki pages when the page has the read-only attribute set and the user does not have `WIKI_ADMIN`, regardless of `WIKI_MODIFY`, `WIKI_DELETE` and `WIKI_RENAME` permissions. It returns `None` for all other cases. |
| | 312 | |
| | 313 | When active, the [#AuthzPolicy] should therefore come before `ReadonlyWikiPolicy`, allowing it to grant or deny the actions on individual resources, which is the usual ordering for `AuthzPolicy` in the `permission_policies` list. |
| | 314 | {{{ |
| | 315 | [trac] |
| | 316 | permission_policies = AuthzPolicy, |
| | 317 | ReadonlyWikiPolicy, |
| | 318 | DefaultPermissionPolicy, |
| | 319 | LegacyAttachmentPolicy |
| | 320 | }}} |
| | 321 | |
| | 322 | The placement of [#AuthzSourcePolicy] relative to `ReadonlyWikiPolicy` does not matter since they don't perform checks on the same realms. |
| | 323 | |
| | 324 | For all other permission policies, the user will need to decide the proper ordering. Generally, if the permission policy should be capable of overriding the check performed by `ReadonlyWikiPolicy`, it should come before `ReadonlyWikiPolicy` in the list. If the `ReadonlyWikiPolicy` should override the check performed by another permission policy, as is the case for `DefaultPermissionPolicy`, then `ReadonlyWikiPolicy` should come first. |