Edgewall Software
Modify

Opened 11 years ago

Last modified 3 years ago

#7650 new enhancement

authz_policy.py - Support Trac groups

Reported by: gw.trac@… Owned by:
Priority: normal Milestone: unscheduled
Component: general Version: 0.12dev
Severity: normal Keywords: authzpolicy groups
Cc: leho@…, mmitar@… Branch:
Release Notes:
API Changes:

Description

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

Attachments (0)

Change History (12)

comment:1 by Dustin Spicuzza <dustin@…>, 11 years ago

Resolution: duplicate
Status: newclosed

This appears to be a duplicate of #6680

comment:2 by lennert@…, 9 years ago

Keywords: authz groups added
Resolution: duplicate
Status: closedreopened

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.

comment:3 by Remy Blank, 9 years ago

Milestone: unscheduled

comment:4 by lkraav <leho@…>, 9 years ago

Cc: leho@… added

comment:5 by lennert@…, 9 years ago

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

comment:6 by Mitar, 9 years ago

Cc: mmitar@… added

comment:7 by gw.trac@…, 9 years ago

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.

in reply to:  7 comment:8 by lennert@…, 9 years ago

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

comment:9 by Christian Boos, 8 years ago

Keywords: authzpolicy added; authz removed

comment:10 by anonymous, 7 years ago

I would love to have this feature, is there a recommend version I should use?

comment:12 by Ryan J Ollos, 4 years ago

Status: reopenednew

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned. Next status will be 'new'.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.