R: [Phpgroupware-developers] ACL and groups

[Marco Palombi]

BTW,

su PHPGroupware il concetto di gruppo e' gia' implememtato....

> -----Messaggio originale-----
> Da: address@hidden
> [mailto:address@hidden conto di Brad Sturgill
> Inviato: giovedì 2 maggio 2002 23.07
> A: address@hidden
> Oggetto: RE: [Phpgroupware-developers] ACL and groups
>
>
> 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
>
>
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers