authz_policy.py - Support Trac groups

[gw.trac@…]

The plugin doesn't support Trac groups (under Admin/Permissions? there is an option "Add Subject to Group") and it is a little strange that you need to define groups in a special file.

Therefore I made a patch against source:/trunk/sample-plugins/permissions/authz_policy.py@7457​ that adds this functionality in a little ugly way. It could be done better, therefore this comment. You can obtain it on ​http://gw.tnode.com/0149-TracDevelopment/.

[Dustin Spicuzza <dustin@…>]

This appears to be a duplicate of #6680

[lennert@…]

This is not a duplicate; it points at a totally different issue.

The authz_policy config file defines groups. Trac also defines groups. These groups are not related in any way. It is perfectly possible to have a group "administrators" in Trac which contains John and Jack, and define a group "administrators" in the authz_policy configfile which contains Joe, and not John or Jack. This also means that the only way to edit the fine grained permissions, seems to be logging in to the shell and manually editing the authz_policy configfile. Great fun if you want to do fine grained permissions on a wiki.

This functionality could be improved *bigtime* if authz_policy would actually support Trac groups, instead of keeping its own set of shadow groups that are not managed by any of the web admin tools.

[rblank]

PatchWelcome.

[lennert@…]

I made the following changes to authz_policy.py:

223     def authz_permissions(self, resource_key, username):
224         if username and username != 'anonymous':
225             valid_users = ['*', 'authenticated', username]
226             db = self.env.get_db_cnx()
227             cursor = db.cursor()
228             cursor.execute("SELECT action FROM permission WHERE username='%s'" % username)
229             rows = cursor.fetchall()
230             for action in rows:
231                 if not action[0].isupper():
232                     valid_users += [action[0]];
233         else:       
234             valid_users = ['*', 'anonymous']
235         self.log.debug('Valid users and groups for %s: %s', username, ','.join(valid_users))
236         for resource_section in self.authz.sections:
237             resource_glob = to_unicode(resource_section)
238             if '@' not in resource_glob:
239                 resource_glob += '@*'
240             if fnmatch(resource_key, resource_glob):
241                 section = self.authz[resource_section]
242                 for who, permissions in section.iteritems():
243                     if who in valid_users:
244                         self.log.debug('%s matched section %s for user %s', resource_key, resource_glob, username)
245                         if isinstance(permissions, basestring):
246                             return [permissions]
247                         else:
248                             return permissions
249                     else:   
250                         self.log.debug('%s does not match any of valid_users: %s', who, valid_users)
251         return None     

It does what I want - I still have to edit the authz policy file to get ACLs set on specific wiki pages (this could probably be done using a plugin in the web admin) but once the ACLs have been set, all permissions are set using the standard Trac groups. Do note that this will no longer process the internal authz groups as they might conflict with the builtin groups. I don't consider this an issue but it's worth mentioning with big bold red letters.

Later on, it might be handy to get rid of the authz file altogether and just use a small DB table to collect ACLs. I have a feeling this is beyond my capabilities though. :-)

[gw.trac@…]

Lennart, your patch is really ugly and even more hackish. First of all it contains SQL code and can't resolve groups as members of groups and doesn't support other authentication backends, second it is a little inefficient (upper case filtering can also be done inside SQL) and the biggest problem is that it contains a possible security hole (I hope you have heard of SQL injections, therefore don't build strings with SQL code in a brain damaged PHP-like way)!

Anyway, an improved and correctly working version of my initial patch can be found on ​http://gw.tnode.com/0149-TracDevelopment/. It also works with different authentication backends and resolves groups as members of groups.

[lennert@…]

Oh, I know the patch is ugly ;-) I'm neither a python nor SQL coder. I'm not really surprised that I made a big gaping security hole there, knowing this...

If it's any consolation, I reverted this and didn't look at it anymore about a week or so after posting here since I wanted to have full integration with LDAP, which this patch of mine obviously couldn't do - so I did some more dirty tricks (​http://vanalboom.org/node/15). Your new patch seems to be much more generic so maybe I can revert this too and go back to a clean untouched trac. :-)