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

Jeroen Huinink j.huinink at wanadoo.nl
Thu Mar 27 12:07:28 PST 2003

Hello Everybody,

"Jan Schneider" <jan at horde.org> wrote on the dev list:
> Quoting Jeroen Huinink <j.huinink at wanadoo.nl>:
> > Ok, so I wasn't the only one that felt this was missing. I'll look into
> > this. I'm not promissing to do anything about it though. ;-) Do you
> > this should be based on Perms or do we need a separate mechanism?
> Perms of course. I feel like this belongs to the registry where the
> application lists get built so that the menu contains only allowed
> applications. The applications themselves can ask the registry if they are
> allowed for the current user, similar to or as a replacement for the
>  "if (Auth::getAuth())" calls.

I agree, but there is more...

"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
> perms won't show up in the perms.php list), Whups, Midas, etc...

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 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
objects. This seems to be the complete opposite of what is actually
happening in all applications that use Perms. As Chuck wrote: you do not see
any of these permission, so what is the use of the permissions module in the
administration sections or what is the intended use? (I think Patricks
question is not answered or the actual point is dodged... ;-))

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. I didn't investigate
whether application themselves define more levels, but I'm assume that they
do or will want to. For example we use the Mantis bugtracker and within each
project you can define a role to a user, e.g. reporter, developer,
administrator etc. I could also imagine that Gollem will be used as some
sort of download manager where you want to give some users read only access
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
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.

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.


More information about the horde mailing list