Fine grained permissions for Wiki pages

[MishaS]

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

{{{
#!authz

* =

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.

[utopiste]

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

[projectname_wiki:/path/to/wiki/page]
someuser=r
otheruser=rw
thirduser=
}}

[cmlenz]

So this isn't going to happen for 0.9.

[anonymous]

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.

[anonymous]

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.

[puffy]

Please see the WikiRBAC patch on trac-hacks.

[anonymous]

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.

[cmlenz]

#2768 has been marked as duplicate of this ticket.

[eblot]

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

[dcrosta]

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.

[athomas]

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

[mgood]

The PermissionPolicy is scheduled for 0.11.

[anonymous]

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...

[cboos]

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 ;)

[kkatzke@…]

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

[cboos]

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.

[anonymous]

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...

[athomas]

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.

[cboos]

This is a must have for 0.11.

[athomas]

TracDev/SecurityBranch merged in r5514.