Complete ACL management

[utopiste]

The Authz support inside trac do some work, we have some wiki not official patch, but we need a more robust ACL system.

Username or groups | Module  | Item       | Permission
-------------------+---------+------------+--------------
utopiste           | browser | /path/     | ReadWrite
utopiste           | report  | 4          | Read
utopiste           | wiki    | /secret    |
utopiste           | wiki    | /public    | ReadWrite
cmlenz             | browser | /branches/ | ReadWrite
authentified       | ticket  |            | ReadWrite
anonymous          |         |            | ReadOnly
anonymous          | wiki    | /public    | ReadWrite

The AuthzPerm class will be moving to a ACL class and trac will provide import support to load the auth_mod_authz file inside the db. in the first we can provide a trac-admin interface, but for the 1.0 version a web management interface can be created.

[Jonas Borgström]

But what's the point of storing the authz information in the db if subversion can't use it any longer?

[anonymous]

i expect to support both, currently the ini file parsing is not optimised when file are very large and the directory contain a lot of file. the second reason is that i want a universal fine grained permission class. this feature is for the next release, i expect some discussion in the next week.

[oohlaf @…]

Looks good, but it doesn't really make sense to have two different versions of permissions on browsing the repository. Why not cache it?

Parse the svn authz file and store it along with the last modified date in the database. If the permissions in that file are changed update the database again. Disable the ability to edit it directly in the database.

Or make a ini setting in trac to disable this, which would allow different access control through trac. Which only makes sense if the repository isn't directly accessable through webdav or svn.

[oohlaf @…]

Are you also considering access control based on the component of a new ticket or report? For example, limit the creating of tickets for a certain component to a group op people. From the table above I see limiting reports based on it's number.

Something along the lines of:

Username or groups | Module  | Item             | Permission
-------------------+---------+------------------+--------------
authenticated      | report  | secretcomponent  |
authenticated      | ticket  | secretcomponent  |
utopiste           | report  | secretcomponent  | read
utopiste           | ticket  | secretcomponent  | readwrite

[Christopher Lenz]

As I see it, this is definitely not going to happen for 0.9.

[Matthew Good]

#1586 has been marked as a duplicate of this ticket.

[Matthew Good]

This should be supported as part of the PermissionPolicy work planned for 0.11. Alec: if you already have another ticket covering this it's probably safe to close this ticket.

[anonymous]

(reassign owner to correct username)

[Alec Thomas]

TracDev/SecurityBranch merged in r5514. A sample plugin implementing authz based access control is included as an example.