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

[Jeroen Huinink]

"Marko Djukic" <marko at oblo.com> wrote:
> Quoting Jeroen Huinink <j.huinink at wanadoo.nl>:
> > 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.

Let me try to rephrase point 4. There can only be a parent-child
relationship between permissions if there is a parent-child relationship
between the objects the permissions apply to. E.g. (I'm not sure if it is
actually implemented like this) a whups module has a permission. The
permissions of every ticket in the module are children of the module's
permission. Does this clarify my statement?

> > 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.

That's how it is at this moment. I was thinking that we could replace the
'admin' setting in the conf file through a generic permissions mechanism. I
cannot think of reasons why we couldn't do this. And it seems to me that
there is an advantage in that you have one mechanism to verify user access
to a certain page or function, some pages require a user to have admin
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.

As for the guest users: at this moment the concept of a guest user is an
unidentified user. I could image that you want to give some identified users
the same access as an unidentified user. The unidentified user also gets a
set of permissions, same as a logged in user. Within the generic framework
you could state that an unidentified user has access level none (meaning
guests are not allowed) or some other access level (e.g. a reporter level in
whups).

> 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.

I'm not sure if I see what you mean. We're not thinking along the same lines
here. I was thinking that we define e.g. _PERMS_GUEST, _PERMS_USER,
_PERMS_POWER_USER and _PERMS_ADMIN and to every page or function add an
authority check e.g. if (Auth::userLevel() => _PERMS_ADMIN). This all comes
on top of or next to what there currently is. So we keep your _PERMS_CREATE,
_PERMS_MOVE and we first check if somebody has the appropriate level before
we check whether he is permitted to perform the operation for the specific
object.

> 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.

Ok, but
1. in Whups how can I specify that a reporter can create new tickets and add
comments to his own tickets, but not to other tickets?
2. in Whups how can I specify that a developer can change specific
attributes, but not change assignments?

Do you want to solve this by defining _PERMS_ADD_COMMENT,
_PERMS_CHANGE_ASSIGNMENT etc like you did for _CREATE and _MOVE?

> > 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.

Yes, but are you saying that you would like to add a permission for every
page or function that requires authorization? Are you suggesting something
like:
if ($perms->hasPermission('horde:page:' . $_SERVER['PHP_SELF'], $userID,
_PERMS_READ))  at the start of every page or something similar within
specific functions? I can see this working, but wouldn't this require a
tremendous lot of permissions and an awfull lot of administration?

> 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.

If this is the only thing you want to do with this then I agree but I see
some other possible uses which require something more.

[The additional points Marco made only relate to Perms itself and not to
application permissions. I do not really have ideas or opinions on this so I
deleted them from this reply.]

Regards,
Jeroen