RE: [Phpgroupware-developers] ACL and groups

[Brad Sturgill]

Ralf,

Thanks for this description.  I have a rather interesting question that may
lead to new functionality if more people are interested in the idea.

I have multiple groups, which can be thought of as separate "companies".
These companies, at times, work together, and at times work independently.
Meaning that there are virtual groups that are formed to work on distinct
"opportunities".  These groups/individuals need to be able to grant the
ability for another group to see distinct units of work (i.e. specific
addressbook entries, or distinct projects, distinct infolog entries (by
addressbook entry).  This means that one group would like to be able to
share information about company ABC with group 1 only, and share information
about company STU with group 2 only.  It looks to me that the was the acl
class is written today, I could share the "all" entries in the addressbook
(or project or ...) but not individual entries.  Correct?

Is the acl the right way to try to develop this type of functionality?  Is
there an existing way of attempting to meet this need?  Is there anybody
else that needs this type of functionality?

-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf Of Ralf Becker
Sent: Wednesday, May 01, 2002 12:51 AM
To: address@hidden
Subject: Re: [Phpgroupware-developers] ACL and groups


Hi Peter,

I attached an answer to your Questions, I wrote one year ago. All the
sugestions - like the group-level ACL - are implemented by now.

As an examplte you may look at my infolog, but basicly all general apps
should be ok as an example how the ACL works.

Ralf

Peter Moulding wrote:

 > Perhaps someone could explain the way ACL and groups are supposed to
 > work. They seem to work in a way that is as spooky as shell scripting or
 > some of the things you see in Perl code.
 >
 > I thought I would set the default group with access to addbook (that
 > wonderful new code) so everyone would have instant access. They did not.
 >
 > Now I am confused. Even after my morning double shot skim cap, I still
 > do not see how the groups fit in.
 >
 > If I put fred in group xxxx, does xxxx add to the default or replace the
 > default?
 >
 > If I put fred in group xxxx and yyy, then give xxxx access to addbook
 > but not yyy, what does fred get?
 >
 > I looked in some code and found inconsistencies. Which application is
 > the perfect example of how an application is supposed to use ACL?
 >
 > Peter
 >
 >
 > _______________________________________________
 > Phpgroupware-developers mailing list
 > address@hidden
 > http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
 >
 >

----------------------------------------------------------------------
Hi Darryl (and to everyone who hadn't looked so deep into the ACL'l),

an ACL entry grants access to a certain resource, grants means you give
someone or some group (this is already implemented) certain rights
(read, add, write, delete, access private items, ...) on your data.

For example I grant the group 'xxx' read-access to my calendar, then
everyone from this group can read (nonprivate) entries of my calendar.
This does _not_ mean I get any rights (in return) on the calendars of
the other members of this group.

So if you as an admin want to implement a setting where everyone in the
group 'employees' grants read-access (for nonprivate) calendar-entries
to everyone else in this group, you have to log in with the name of each
member an grant read-access to the group 'employees'. You have to do
this again for each new member of this group, it is not sufficient to
add someone to the group.

My idea is to grant (as a group / as admin for the group) access to a
resource to a person or a group. If the admin now wants to implement the
above setting, he has just to grant read-access _from_ the group
'employees' to the group 'employees' and that's it. If he adds new
members to this group, they got imediatlty access to the other calendars
(and of course grants the others access to theirs).

To implement it, just have a look how the ACL class works today: if a
script reads an entry (lets they to show all addresses) it first look if
the user is the owner, than he gets automatically all rights. If not the
scripts asks the ACL class to get the grants of this user. The ACL class
now scans the database for grants to the user and his group(s). The
grants are collected in an array (with the person giving the grant as
key) by or-ing them together (the array has as an other dimension the
name of the application, as we look in this example to the addressbook,
we only need to look at that dimension and ignoring the rest).

For example we have the group ABC (with the members A, B and C). User A
grants read-access to group ABC and write-access to user B, C grants
read-access to A (_not_ to B or group ABC). The grants for user B would
looks like:
        $grants = array( A => read|write );
(where A, B and C is the numeric user_id and read is the constant
PHPGW_ACL_READ).
Please note that their is no entry for B as well as none for C.

To check if the user has read access to an entry the script looks (after
checking the user is not the owner) if the read-bit is set in the grants
of the owner (not the user):
        ($grants[$entry['owner']] & PHPGW_ACL_READ) != 0

To implement my idea, the ACL class would, if their is an ACL entry
_from_ group ABC, expand it to entries for each member of this group,
and then deals with them like usually. This means there's no change in
application code necessary to deal with the new functionality.

For example the group ABC (the admin for them) grants read-access to
group ABC and user A grants write-access to user B. The grants for user
B would look like:
        $grants = array( A => read|write, B => read, C => read);

Remark: Maybe the ACL class should return PHPGW_ACL_ALL == ~0 for the
user itself, than app's don't need to check if the user is the owner
anymore (no problem if they do).

About how to get grants _from_ a group in the database have a look at my
original posting.

I hope that helps to understand my idea (and maybe a bit more the ACL)

Ralf

Darryl VanDorp wrote:

 >
 > Seek3r
 >
 > I think what this idea speaks to is nobody
 > (or very few) understand the ACL scheme
 > completely.
 >
 > What we could all use is some cool
 > examples,theory, and general
 > usage guidelines for the mighty
 > ACL.
 >
 > --Cheerio
 >
 > Maniac
 >

 > >
 > > Ralf Becker wrote:

 > > >
 > > > I would like to be able to grant access based on the group of a user.

 > >
 > > The ACL supports this already
 > >

 > > > This means for example all user in group xxx grant read access of
their
 > > > addressbook to each other. This could be set by the adminstrator
and has
 > > > not to be set for each new user manually.

 > >
 > > If it doest already support it, it should be easy to add.
 > >

 > > > It could be accomplished within the ACL-class without changing
any app:
 > > > - If an app asks for the grants the ACL class looks not only for the
 > > > grants of a user, but the grants of his group(s)

 > >
 > > The ACL does this automaticly
 > >

 > > > - the grants could be set via a link in admin/editgroup for each
app to
 > > > preferences/acl_preferences.phpacl_app=<app>&group=<group>

 > >
 > > Basicly, yes
 > >

 > > > - all necessary fields are allready in the databases

 > >
 > > Yep
 > >
 > > Seek3r
 > >
 > > _

 >
 > _______________________________________________
 > Phpgroupware-developers mailing list
 > address@hidden
 > http://lists.sourceforge.net/lists/listinfo/phpgroupware-developers


--
----------------------------------------------------------------------
Ralf Becker OUTDOOR UNLIMITED Training GmbH Telefon +49 (631) 31657-0
Leibnizstraße 17 Telefax +49 (631) 31657-26 D-67663 Kaiserslautern
(Germany) EMail address@hidden


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