[dev] Application Permissions (was Re: appLinks() and Re: About permissions)

[Marko Djukic]

Quoting Jeroen Huinink <j.huinink at wanadoo.nl>:

> Hello Everybody,
>
> "Chuck Hagenbuch" <chuck at horde.org> wrote on the user list:
> > Quoting Dr Patrick Atlas <patrick.atlas at mg-france.fr>:
> >
> > > I can't find what is the purpose of the permission module in the
> > > administration trivia of horde.
> >
> > Well, it lets you manage permissions for anything in Horde that uses them.
> > Examples of what use them are shared tasklists/calendars/etc. (though
> those
> > perms won't show up in the perms.php list), Whups, Midas, etc...

it would be good to actually have in some way a generic permission editor that
could be easily adapted/extended by the apps that use them, to also fit the
style/ui of the apps. i've been thinking this the last few weeks, because i
don't see the point in designing a custom permissions code for each app that
requires some permissioning - for example the ones i'm working on giapeto,
midas, scry, agora...

> I have been pondering this for the last two days and examining the code and
> from this I draw the following conclusions.
>
> 1. A "Permission" is some sort of access control list.
> 2. You apply a Permission to an object of some kind.
> 3. The Permission name identifies the object (and the application and the
> type of object).
> 4. A parent permission always is the permission of a parent object.
>
> Is this correct?

i believe so, but i don't understand your point 4 though.

> I have also taken a look at the permission module in the administration
> section and I feel that it is useless at the moment and furthermore it is
> confusing. From the permission module you get the impression that you can
> define a permission (or set of permissions) and apply them to arbitrary

it is useful if you know what objects need to be set, but totally useless if you
haven't read very thoroughly the code. ie. quite unlikely. see my point below
about a uniform perms UI.

> Back to the original issue: defining permissions for applications. The
> obvious use for this is showing specific applications to specific users in
> the Horde menu. There are however also various user levels at the moment:
> admin, user, guest with different sets of capabilities.

"admin" you can consider separate, it's what's set in the conf.php file and
should have total permissions.
then the guest/user are essentially two different states - user has not logged
in, user has logged in - after which you can start fine tuning the permissions
based on user/groups.

> and others read-write, etc. If we come up with permissions for applications
> do we want to capture different user types as well? If so, how do we map
> these upon the current set of permissions:
>
> define('_PERMS_NONE', 1);
> define('_PERMS_SHOW', 2);
> define('_PERMS_READ', 4);
> define('_PERMS_EDIT', 8);
> define('_PERMS_DELETE', 16);
>
> Do you think this would be possible? I think that this will bend things
> awfully. My thoughts are going in the direction of defining different user
> levels e.g. NO_USER, GUEST, USER, ADMIN and leave room in between for

i prefer the SHOW/READ/EDIT.. i think that is sufficient for defining access to
apps, and for permissions within apps. plus it allows for even finer-grain type
permissioning when needed - to give an example in giapeto i extended Perms.php
to add to those also:
define('_PERMS_CREATE', 128);
define('_PERMS_MOVE', 1024);
since i want to have users that can for example edit pages assigned to them but
not create others. others that i do not want to be able to move pages and
destroy the site tree. the GUEST/USER/ADMIN sounds too rigid. would i need to
define then an ADMIN_CAN_CREATE_PAGE, ADMIN_CAN_EDIT_CANT_MOVE... if you see my
point.

you mentioned Mantis and defining roles - reporter, developer... but you can
already achieve the same effect currently with Perms. Define a group "reporter",
and another "developer" and assign the desired permissions to them. then just
add to and remove from these groups the users and you have "roles" in a way,
without having to deal with users and permissions individually.

> applications to use. I didn't investigate whether the Perms class could be
> extended to provide for something like this as well. The current permissions
> define access to objects where what I would like to have is something to
> define access to functions/pages.

can't you consider functions/pages as objects? i see them as such.

> I agree with Chuck that there should be a *really* good reason to do
> something next to Perms. I am not arguing this (yet ;-)). I'm just trying to
> put my mind together on how to implement this and see whether it is usefull
> to incorporate the guest and admin level access as well.

i think we are on the right track with Perms as they are currently. i find that
they provide a great deal of flexibility. the points that i think need work on are:
- defining some sort of root namespace for applications within the Perms to
which permissions could be assigned and that the registry could read. this could
allow for setting what apps are seen or not in the horde menu for example. i
think we have almost all we need in the Perms, just needs a way for the Registry
to read it and a good UI to set these up.
- having a uniform access to the Perms from various apps. the current UI is not
very useable - apps should "advertise" a predefined set of permissions that can
be set, and have the UI present this for users/groups to be
added/removed/modified... i don't think it should be done that each app makes
its own ad-hoc method of editing permissions, as i started with some of the apps
i am working on.
- having hierarchy within permissions, ie. user FOO has READ/EDIT on object A,
so FOO should be able to set permissions on object A, the same or lesser, to
user BAR. also, inheritance - object B is a child to object A, so user FOO would
have READ/EDIT on object B unless set differently in object B.
this is all possible at the moment, and i am using it to an extent within
giapeto, but it is really lacking a UI to make it efficient and useable across
the spectrum of horde apps.

so i think it mostly comes down to designing a good UI, since i think the
structure is sound.

marko