phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Phpgroupware-developers] New ACL functionality


From: Dan Kuykendall
Subject: Re: [Phpgroupware-developers] New ACL functionality
Date: Fri, 10 Jan 2003 10:28:05 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126

I dont see why it wouldnt.
You will need to make use of IRM's to block all users with rights to your app from having rights to the whole thing, but this is what the design is intended to accomplish.

Sigurd Nes wrote:
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'

very easily done
Heres what you would do:
Use the values as follows
value   - 1     2      4       8       16
right   - read  edit   delete  create  admin


To give rights to the property app you would do similar to now. In current acl you would assign the using
location=run  rights=1  type=0
(note: type 0 is rights, type 1 is mask)

In the new ACL it would be
location=.  rights=1  type=0

This allows the user to get into the app
In your case you will want to (by default) block the user from getting into each of the modules, so you will apply an IRM to each module

location=.property_register   rights=31  type=1
location=.equipment_register  rights=31  type=1
location=.invoicehandling     rights=31  type=1
location=.service_agreements  rights=31  type=1
location=.helpdesk            rights=31  type=1
location=.project_workorder   rights=31  type=1

(note: 31 is the total of all 5 rights to be blocked)

Now when you want to give a user rights to one of the modules you can give them rights directly to the module as desired
(lets give the user read, edit and create rights)

location=.project_workorder  rights=11  type=0

Since its direct it has priority to the IRM, which is supposed to block inheritance not directly granted rights.

The Invoice submodule also has the roles: janitor, supervisor and
budget_resonsible - which I suppose could be modelled as groups

This does act as a useful example of one limitation of the ACL, but one that has several ways to work around. In this case you only mention 3 roles, which actually works out fine for the ACL.

value   - 32       64          128
right   - janitor  supervisor  budget_resonsible

So for the role you can just slap it into the above grant, so instead of:
location=.project_workorder  rights=11  type=0
the janitor would instead get
location=.project_workorder  rights=43  type=0
(added the 32)

Since 128 is the last of the 8 switches that PHP will support as far as I know, you would have to work around it if you have more roles. This is easily done as follows using roles rights.

value   - 1        2           4
right   - janitor  supervisor  budget_resonsible

In this case the janitor would get these two:
location=.project_workorder       rights=11  type=0
location=.project_workorder_role  rights=1   type=0

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?

I hope to have you switch to our ACL as well, since the new ACL will also include a nifty ACL manager interface as well as the plain fact of keeping things as consistant as possible.

Do my examples look like they would solve your needs?

Dan

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







_______________________________________________
Phpgroupware-developers mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/phpgroupware-developers





reply via email to

[Prev in Thread] Current Thread [Next in Thread]