Edgewall Software

Opened 15 years ago

Closed 12 years ago

#654 closed enhancement (fixed)

Fine grained permissions for Wiki pages

Reported by: MishaS Owned by: Alec Thomas
Priority: high Milestone: 0.11
Component: wiki system Version: 0.10
Severity: major Keywords: PermissionPolicy
Cc: kkatzke@… Branch:
Release Notes:
API Changes:


Are there any plans for such a thing? As far as I understood, ticket:157 relates to subversion repository only.

My first idea (I do not know how it's feasible) would be to create a special Wiki Processor (as described in WikiProcessors), for example


* =

authorized = r
bob = rw
harry = rw

the only issue here i see is that those processors can have only one effect — putting some text into output "stream". while in this case, the effect should be somewhat different.

Attachments (0)

Change History (23)

comment:1 by utopiste, 15 years ago

Milestone: 0.9
Owner: changed from Jonas Borgström to utopiste
Status: newassigned

comment:2 by utopiste, 15 years ago

i have done a patch to add this support directly inside the authz file. The patch will be merged after the .9 release


comment:3 by Christopher Lenz, 15 years ago

Component: generalwiki

comment:4 by Christopher Lenz, 15 years ago

Milestone: 0.9

So this isn't going to happen for 0.9.

comment:5 by anonymous, 14 years ago

Fine grained access control is a must-have for many medium to large sized organizations.

We are choosing a Wiki now and we like many features of Trac, but we will have a hard time getting agreement to go with Trac without at least the promise of fine-grained access control within a few months.

comment:6 by anonymous, 14 years ago

In order to keep fine-grained access control manageable, we would need to be able to specify access permissions for SubWikis?. For example, if we specify that Gabrielle is allowed to edit SomeStuff?, then she should also be allowed to edit SomeStuff/SomeDetails? and SomeStuff/MoreDetails?, and even SomeStuff/MoreDetails/ReallyDetailedStuff?, without having to explicitly add edit permission for all of those pages.

comment:7 by puffy, 14 years ago

Please see the WikiRBAC patch on trac-hacks.

comment:8 by anonymous, 14 years ago

one of the most useable acl for wikis is that one of moinmoin. it is web-administrable by default: http://moinmoin.wikiwikiweb.de/ACL_for_Extended_Names. i used this link because of the acl format. roles and users are anyway already there in trac.

comment:9 by Christopher Lenz, 14 years ago

#2768 has been marked as duplicate of this ticket.

comment:10 by anonymous, 14 years ago

Milestone: 0.10

comment:11 by Emmanuel Blot, 14 years ago

Milestone: 0.10

Please do not define the milestone without a justification if you hide your identity (anonymous)

comment:12 by dcrosta, 13 years ago

as observed above, the ACLs in MoinMoin are quite powerful, but sometimes confusing. moreover, the text-based ACLs mixed in with the wiki page itself is confusing, and not necessary considering that Trac uses a relational data store rather than a single flat text file for each wiki page. i'm imagining something like this:

  1. store ACLs as a separate table, which references a role name (a 'group', a user, or 'anonymous' or 'authorized') and a wiki page, and also the permission (view, edit, delete) and sense (allowed or denied)
  2. evaluate ACLs with this precedence: username, groups, specials (anon or auth), and when there's a conflict with several groups having differing permissions, take the most permissive (this is debatable, but i think the most permissive makes most sense)
  3. when no rule matches (wiki page, user, action), fall back on the global rules as set through trac-admin

unfortunately, this places some of the access control out of the scope of what the webadmin plugin can currently handle… there'd need to be improvements in that interface as well as an interface in the wiki pages themselves to control this

the interface in the wiki page could list each user/group for which a rule is defined, and allow the user to select the sense for each action — allowed, denied or no rule.

comment:13 by Alec Thomas, 13 years ago

Owner: changed from utopiste to Alec Thomas
Status: assignednew

You might want to have a look at the PermissionPolicy (security) sandbox and the AuthzPolicy plugin which leverages it.

comment:14 by Matthew Good, 13 years ago

Milestone: 0.11

The PermissionPolicy is scheduled for 0.11.

comment:15 by anonymous, 13 years ago

Keywords: PermissionPolicy added; authz removed

I just read that PermissionPolicy is "Likely to be post-poned for 0.12". I think this is a really important thin. I'm struggling in enabling some of the Wiki-Pages publicly and keeping the rest restricted because they contain confidential information.

I hate those workarounds. Please keep an eye on that very soon…

comment:16 by Christian Boos, 13 years ago

Well, I for one was for the inclusion of the PermissionPolicy branch in 0.10, as it was really not a disruptive change at that time…

If anyone revives the branch and would like to propose a patch against 0.11dev, this will make it less like to be post-poned again ;)

comment:17 by kkatzke@…, 13 years ago

Looks like PermissionPolicy made it into 0.11, as of r4600. What's the status on using PermissionPolicy for wiki pages?

comment:18 by kkatzke@…, 13 years ago

Cc: kkatzke@… added

comment:19 by Christian Boos, 13 years ago

Not completely, as the branch has not been merged in trunk yet. This is still discussed in Trac-devel. But yes, as currently implemented in the source:sandbox/security branch, fine grained permissions for Wiki pages, tickets and attachments do work as expected. The extension to other resources (milestone, source and changesets) will be done once in trunk.

comment:20 by anonymous, 13 years ago

I've got Trac 0.11dev-r5198 installed — how can I get the AuthzPolicy PermissionPolicy feature from the Security Sandbox installed on my local Trac installation? Or does anyone know if the WikiRBAC plugin would work for Trac 0.11?

This is exactly what I'm looking for in order to be able to start using Trac for my needs, and it would be really helpful if I could find a way to get it to work…

comment:21 by Alec Thomas, 13 years ago

There is a proof of concept in source:sandbox/pycon/security, however it currently only applies policy decisions to the Wiki. This will likely be in Trac 0.11.

comment:22 by Christian Boos, 13 years ago

Priority: normalhigh
Severity: normalmajor

This is a must have for 0.11.

comment:23 by Alec Thomas, 12 years ago

Resolution: fixed
Status: newclosed

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Alec Thomas.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from Alec Thomas 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.