RE: [Phpgroupware-developers] New ACL functionality

[Sigurd Nes]

In my property application - I have currently 5 submodules (now moving
to xslt in HEAD)
        - property register
        - equipment register
        - invoicehandling
        - service agreements
        - helpdesk
        - project/workorder

Each separate submodule is controlled by the rights: 'admin', 'read',
'edit', 'delete' and  'create'
The Invoice submodule also has the roles: janitor, supervisor and
budget_resonsible - which I suppose could be modelled as groups


I have built my one ACL that works for me - but I am eager to be able to
use the standard phpgw ACL.
Will the new ACL support my needs?

Regards

Sigurd 

 
> I am well underway on this new ACL and decided to step back a little
and
> explain how it works and what it can do.
> 
> I have all the basic functionality working in code now and am just
> filling it in and making it all a clean object to be able to replace
the
> current ACL (which after this re-write proves to perform terribly and
> has overly complicated design with a majorly lacking feature set.
> 
> The major new features are that it now supports inheritance, inherited
> rights masks, nested memberships (not yet explained in the following),
> better performance and cleaner more understandable code.
> It no longer has the concept of explict deny because rights masks can
> accomplish the same thing and are more flexible.
> 
> Heres an explaintion of how it works overal.
> This is the first draft and would greatly appreciate help in cleaning
> this up.
> -------------------------------------------------------------
> To help understand how the ACL works it requires an understanding of
bit
> set operations. This probably sounds more complicated than it is so I
> will explain here.
> 
> Bit switches:
> Lets look at it as a series of 8 switches that can be used to
represent
> any number between 1 and 256
> The values of the switches are as follows
> switch - 1   2   3   4   5   6   7   8
> value  - 1   2   4   8   16  32  64  128
> 
> To get a value you just turn on the switches which will add up to the
> desired value
> So the value of 3 would mean switches 1 and 2 are turned on.
> The value of 20 would mean switches 5 and 3 are on. 5th value of 16
plus
> 3rds values of 4 = 20.
> For 256 we would turn on all switches
> 
> Using switches to represent rights:
> In ACL's we think of each switch as a right, so lets look at them as
> follows
> switch  - 1     2      3       4
> value   - 1     2      4       8
> right   - read  edit   delete  create
> 
> I am only using the first 4 switches in this case and thats fine.
> 
> So if I want a user to have read and write access I would add a record
> with rights = 3
> To give them read, edit and create rights I would give the user rights
=
> 11 (values 1+2+8)
> rights = 15 would give them all four of the rights.
> 
> Adding rights/switches (not your normal math):
> When I add up a users rights with their rights given to them by their
> groups I simply flip switches using bit math operations.
> So lets say a user has rights of 11 (read, edit delete) and is a
member
> of group1 which has rights of 10 (edit, create). If you use normal
> addition you would end up with 21 which is not what we want. 21 would
be
> switches 1, 3 and 5 and the user would not have the correct rights.
> So using bit operations it works as follows.
> User rights of 11 turn on switches 1, 2, and 3.
> Group1 rights turn on switches 2 and 4
> Notice switch 2 was turned on twice, which basicly means the second
time
> did nothing.
> So now when I look at the value it is 15 as we want.
> I hope your following so far, but even if you dont understand fully
read
> on to see how this is put into action for powerful inheritance and
> masking.
> 
> Inheritance:
> We support rights inheritance in our ACL.
> Basicly you can think of this easiest as a directory model.
> Lets say you have a directory of c:\data and you have read, and create
> rights.
> Inheritance would mean that you have both read and create rights to
> c:\data\subdir1
> You can also have specified edit and delete rights to c:\data\subdir1
> thereby giving you all 4 rights
> So when I do is first go to the top dir c:\data and get your rights,
> then get the rights to subdir1 and add them together using bit math.
> This hold true for c:\data\subdir1\docs. First I will check c:\data,
> then c:\data\subdir1 then
> c:\data\subdir1\docs and add up as I go.
> 
> Inherited Rights Mask (IRM):
> IRMs take the action of removing rights or you can think of it as
> turning off switches.
> Lets look at the example again: c:\data\subdir1\docs
> At c:\data we have read and create.
> At c:\data\subdir1 we have edit and delete
> The effective rights of c:\data\subdir1 will be all four when we
inherit
> from c:\data
> 
> Now lets say we dont want the user to have anything but read rights to
> anything in and under c:\data\subdir1\docs
> For this we will apply a mask for edit, delete and create. Basicly
this
> amounts to turning off those
> three switches at the point the mask is applied.
> Lets look at it like this
> c:\data turn on switches 1 and 4.
> c:\data\subdir1 turn on switches 2 and 3
> c:\data\subdir1\docs turn OFF switches 2, 3 and 4
> 
> Now anything under c:\data\subdir1\docs you only have switch 1 turned
> on, so the user only
> has read access.
> These IRMs are very important to understand in order to allow an admin
> to secure their environment.
> 
> Closing Points:
> If you have any issues with understanding how this all works feel free
> to email me at address@hidden
> It would also be useful to look at Novell Netware's security model,
> because our design closly follows theirs.
> 
> 
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>