capabilities of forthcoming group changes

Jason Pyeron jason at pyeron.com
Wed Jul 9 12:51:53 UTC 2003


On Tue, 8 Jul 2003, Joel Peshkin wrote:

> Forcing restrictions based on the membership of the submitter saying 
> that Group A must restrict to Group A but they don't have to if they are 
> members of both Group A and Group B would be an interesting trick. 
>  After all, your own staff will need to be members of all of these 
> groups and their membership should not require them to restrict bugs to 
> be visible by only other people who are members of all of the groups.
> 
> If anyone has an idea of a consistent way to express this, jump in anytime.
> 
> -Joel

It seems that the current way of representing access control in Bugzilla is well 
exceeded by situations like this. We have been doing the 1 product 1 
customer approach, and we don't like it either. We developed an ACL system 
similar to the NTFS file/directory permission system, but requires 
sub-select/recursion at the SQL level (My-SQL does not support this yet?) 
for Oracle/DB2. We store the groups/users as a graph, a user is a leaf 
node.

at any node there is a hash, a value of any key is (set, unset, inherit, 
disinherit, toggle)

the SQL works by stepping up the graph (from your node) then selecting 
down the graph, sorting, removing duped rows, etc. When the query returns 
you have the permissions list for a given user or group.


I think it can easily be done as query in a loop technique, and still have 
respectable efficiency.


Now on to the why do it this way...

1. Groups can have children.
2. Groups can have multiple parents.
3. No limits on groups / users.
4. New groups can be inserted anywhere/anytime.

5. Rules can be defaulted at any hierarchal level.
6. No limit on rules.
7. New rules can be added without regard to other rules.

8. Administrators feel natural with tree based ACL.

9. Multiple parental conflicts are resolved by parental priority.
 OR (system design option)
9. Multiple parental conflicts are resolved by rule value priority.

I jumped in, but we can't do this any time soon, we are already backed up 
on the Java port / client installations. Feel free to pick my brain on 
this.

Sincerely,

Jason Pyeron

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                   http://www.pyerotechnics.com   -
- Owner & Lead                  Pyerotechnics Development, Inc. -
- +1 410 808 6646 (c)           500 West University Parkway #1S -
- +1 410 467 2266 (f)           Baltimore, Maryland  21210-3253 -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you 
have received it in error, purge the message from your system and 
notify the sender immediately.  Any other use of the email by you 
is prohibited.






More information about the developers mailing list