Is it possible to place the permissions scheme inside of each component and just define the API? This gives you most of the pros of each system. Especially if the implementations of the API do not store permission data which matches the "default" (ie, if read-only is the default, no data needs to be stored for users with read-only access).

• Flexible - components can be added/removed/reshuffled
• Maintainable - Permissions are packaged with the objects
• Simple - if ( $obj->is_readable($id) ) is fairly clear

• Planning - More up-front work needed (is this a con?)
• Insular - Permissions are opaque between components

Probably more cons I haven't thought of.

Thanks for the feedback.
Let me say that more up-front work is definitely not a con =]
I am a firm believer that a little more work up-front can save a lot of work on the backend.
Really, I think the biggest issue with a permissions system is how to store a user's assigned permissions. This will then generally dictate how permissions are stored. The plan is to create a class that does nothing but answer authorization questsions something like the following pseudo-code:


class Authorize
{
    constructor( string user )
    {
        # get user permissions from persistent storage
    }

    hasPermission(PermissionPrimitive perm)
    {
        # compare user's permissions with given primitive
        # and return true or false accordingly
    }
}
[download]


Of course this scenario would probably have more methods, but those two are really the core functionality.
Given this scenario we have a central place to store a user's permissions and a central place for querying the user's permissions. This allows for the system as a whole to be ignorant of permissions, and puts the power into the specific components that will actually need authorization information.

Then you also have to either place business logic about how permissions react with each other in those methods, or rely on general statements about permissions -- like they are always additive or the minimalistic. Either way limits you on how permissions that are inherently tied together can work (think requisite permissions). also exclusive permissions are hard to deal with as well.


-Waswas

From memory, C++ code would work something like:

   CMode mode = new CMode("abcd*eAB");
   mode = "beB"; // mode.Clear(); mode.SetModes("beB");
   mode += "a";  // mode.SetModes("a");
   mode -= "b";  // mode.ClearModes("b");
   mode += "d Jones"; // mode.SetModes("d", "Jones");
   if (mode & "a") { ... } // mode.IsModeSet("a")
[download]

The special handling of "d*" meant that mode "d" took an argument, and you could have any number of them. (Kinda like "/mode #chan +b n!i@h" on IRC.)

Limits, similar to that of bitfields, are that you have a fixed and arbitrary set of fields. Benefits over bitfields are that it's fairly easy to expose the flags to the end user in a consistent way.

--
[ e d @ h a l l e y . c c ]

As for storing the hash to a database (and reading it back), there are lots of ways to do this, but perhaps the most practical would be a table entirely devoted to storing permissions: each row would hold "username", "componentname", and "permstring"; the "username, componentname" tuple would serve as a primary key (two components can't have the same name, and one user can't have two different permission settings for the same component).

With such a table, you can "select * where componentname='X'" and see all the users and their permissions associated with that component, or "select * where username='Y'" and see all the components this person is registered for, and what his/her permissions are for each one.

Maybe you want the permission information to be "global" in some way (all contained in one hash, accessible to all components), or maybe it should be set up so that only the database keeps the "global" picture, and each component only fetches and holds the permission data it needs. With a simple permissions table and an object class to manage it, you could go either way. You're also free to choose where to implement dependencies (e.g. users who can do X should all be able to do Y), though it will probably be best to handle this in the components, or in the code that glues components together -- keep the permissions object simple and general-purpose, rather than cluttering it up with stuff that is based on knowledge about what the components actually do.

(Of course, some dependencies are generic no-brainers, like "if you can execute this, you have to be able to read it"; this sort of thing belongs in a "Perms" module.)

update: This train of thought could just lead to a heavier reliance on the database, querying the permissions table whenever something needs to be checked rather than maintaining a perl-internal hash; in that case, you would probably want the different types of permissions (read, write, execute, etc) as separate columns in the table, to allow more efficent indexing and fetches. A "Perms" module would still be useful, to help integrate/migrate the table data for components and users. Keep in mind that it's easy to add columns to an existing table, in case you come up with new types of permissions later on.

I don't understand why the 64 bit limit is a problem. The bits are used to identify operations. The user id should be stored in another field.

There is no possible way your users will think about the security of 64 different operations. Maybe I'm missing something though. Could you list some of the "real" permissions instead of just the read/write/execute example?

I designed a security module that stores object permissions in an ACL table. Each different operation is given a column in the ACL table. If the value of the column is even, permission is denied; if the value is odd, permission is granted.

The data model looks like this:

ACL (
  item_id integer,
  group_id integer,
  read_access integer,
  write_access integer,
  create_access integer,
  delete_access integer
  ...
)

-- All objects with security assignments have
-- an entry in the item table. Common attributes
-- such as owner, creation date, data retention
-- schedule, dispose-by date, etc. are stored
-- here too.

ITEM (
  id integer,
  ...
)

-- The session table is updated when a person
-- logs in. Hierarchical group memberships are
-- flattened out and inserted into the session
-- table.

SESSION (
  user_id integer,
  group_id integer
)
[download]

Each different object class can implement its own has_user_access method. The base class method does a simple ACL test using this query:

  select max(read_access)
    from acl, session
    where acl.group_id = session.group_id and
          acl.item_id = :ITEM and
          session.user_id = :USER
[download]

The results of these security tests are cached only for the immediate operation (Apache request object). I use a bit-field, but since it is just a cache, the implementation can change without affecting any other code. After the operation is complete, the cache is thrown away so that security information can not leak between user sessions. (It is not as horrible as it sounds -- the database keeps its own cache so these checks rarely hit the disk.)

I work with a big, bad, broad application with similar permissions requirements.

The handled it by creating an "administrative" object with permissions attributes and user attributes. These objects can work systemwide or be assigned to specific objects in the system.

So for example the "root" user would be subscribed to an administrative group with global "superuser" permissions.

A "peon" user is subscribed to an administrative group with global "user" permissions and admin permissions over their mailbox.

It's cumbersome (the app I deal with does not let a user subscribe to multiple administrative objects) but effective.

package main;
use User::Permissions;
use User::Permissions::Node;
use User::Permissions::Page;

my $up = User::Permissions->new(user_id => 1);
my $up_page = User::Permissions::Page->new;

warn "can read nodes" if User::Permissions::Node->read; # package call
warn "can read pages" if $up_page->read; # object call

# ... later ...
package Foo;
use User::Permissions;
use User::Permissions::Baz;

my $up = User::Permissions->new(user_id => 1);
warn "can write baz" if User::Permissions::Baz->write;
[download]

sub setpermbybitnum { my $vec=""; vec($vec,shift,1) = 1; $vec }

# check if any perms are set
sub no_perm { "$_[0]" =~ tr/\0//c == 0}

# check if all specified perm(s) are set
sub has_perms { no_perm( ("$_[0]" & "$_[1]") ^ "$_[1]") }

# check if any specified perms are set
sub one_or_more_of_perms { !no_perm("$_[0]" & "$_[1]") }

use constant READ_PERM => setpermbybitnum(3);
use constant WRITE_PERM => setpermbybitnum(2);
use constant EXECUTE_PERM => setpermbybitnum(1);

my $allowed = READ_PERM | WRITE_PERM;

# Check for permissions:

if ( no_perm($allowed) )
{
    print "PERMISSION DENIED\n";
    exit -1;
}

if ( has_perms($allowed, READ_PERM) ) {
    print "READ Allowed\n";
}

if ( has_perms($allowed, WRITE_PERM) ) {
    print "WRITE Allowed\n";
}

if ( has_perms($allowed, EXECUTE_PERM) ) {
    print "EXECUTE Allowd\n";
}

if ( has_perms($allowed, READ_PERM|WRITE_PERM ) ) {
    print "READ and WRITE Allowed\n";
}

if ( has_perms($allowed, READ_PERM|EXECUTE_PERM) ) {
    print "READ and EXECUTE Allowed\n";
}

if ( one_or_more_of_perms($allowed, READ_PERM|EXECUTE_PERM) ) {
    print "READ or EXECUTE Allowed\n";
}
[download]