.oO(I'm sure I'm teaching my granny to suck eggs, but here goes anyway...)

As far as hierarchy is concerned, why not fall back on the inheritance of methods, accessors & mutators e.g. in your example, Desk->method() resulting in Workflow->method() actually being the method called - thus indirectly implementaing the inheritance of permissions etc. e.g.

package Workflow;

sub method {
  my $self = shift;
  .
  .
  .
}

package Desk;

use base qw/Workflow/;

sub new { bless \( my $scalar ), ref $_[0] || $_[0] }

package main;

my $desk = Desk->new();

$desk->method();
[download]

I think another kind of inheritance is meant.

Perls OOP models inheritance on classes not on objects. Objects have no @ISA.

IMHO the OT has objects of different classes in a hierarchical order

but he may simulate the @ISA behaviour für objects in an instancevariable @upper_rights containing refs to the other objects.

Cheers Rolf

Agreed - but I've played with inheritance at both class and instance level in order to achieve substantially the same, or similar, end-result.
A user level that continues to overstate my experience :-))

> For example, if a Desk is in a Workflow, I'd want the Desk to inherit permissions from the Workflow.

Sounds like you're adding the Desk-object to an array in the Workflow-object. The add-method might take care about dublicating rights, or adding a backlink in Desk to Workflow which is dynamically followed, if Desk's rights are evaluated.

... just my 2¢ of brainstorm interpretation of your question...

CGI::Application can be used to implement role-based access control using the modules CGI::Application::Plugin::Authentication and CGI::Application::Plugin::Authorization.

It's the "implement" part I'm being lazy about. :} I'm probably just dreaming, though, thinking there's something already implemented, since it's probably fairly application-dependent. Also those presumably require using CGI::Application, which I don't necessarily want to do.

I read more about RBAC last night, and it does seem (in an abstract, theoretical way) a lot like what I have in mind. There are apparently a few implementations of it -- especially in Java, which I guess is (fairly or not) more associated with "enterprise" applications.

Access-control on objects is somehow ambiguous. The objects are combination on data and behaviour. So you have 2 levels of access control - on data and on behaviour.

1. On data level. Usually you get and store the data in some sort of database. You could implement your access-control policy there, in the database. For example look for "Oracle label security", for Postgresql look pgacl (row-level ACL), sepgsql (integration with SELinux security model),veil (view-based sec.policies) etc. You could configure inheritable permissions with some of these tools

2. For behaviour level access control - you could code it yourself, it is very application dependant so there is no good, universal model for doing this - you do it one way for webapp, another way for Tk app etc.

You are working on some CMS, I suppose it has some kind of behaviour level access control. Look there and change the code to fully suit your needs

Thanks, especially for the pointer to pgacl.