Question

I’m trying to implement a table row permission system in my database (with a PHP front-end and MySQL back-end). It should follow the Windows File Permission system, in the sense that:

• There are users
• Each user can be a member of several groups
• Each group can be a member of other supergroups
• You can specify an entire group, supergroup or a single user for
  permissions
• Should be: User permission supercedes subgroup supercedes supergroup. (<- not entirely necessary)

The user, after creating the database entry, can specify which groups/users should have which permissions (read, write or leave invisible). When accessing the web front-end, only the entries which they have permissions on should be displayed (using a cookie login system). Only those which they have Write access to should be available for editing.

Basically, I don’t know how to efficiently create the database to relate the user to the permissions they should have on the file (I know, once I get the permission ‘level’, how to do the rest of course).

I’ve tried relation tables, but that got complicated very fast. I tried arrays of User/Group IDs in the file entry itself (as a field for the file), but this was sloppy and only supported 64 entries (as well as being difficult to implement the group/user heirarchies).

Are there any examples, add-ins, anything to help with this? I’m versed in Javascript, PHP, SQL, HTML and their relationships and I’m re-writing an old version using the new PDO extension. I know it’s in the realm of possibility, but every stratagy I’ve tried has just been a nightmare.

Answer 1

If you were using Oracle, you could use role functionality to deal with the hierarchy of groups. Mysql doesnt currently offer this functionality (although it seems to be on a list to do here ).

In the meantime, you could mimic this functionality something like this.
Create a table called roles which has id and name fields and populate with a set of roles.

Create a table called user_role_privs that will hold the direct links from users to a role.

and create a table called role_role_privs that holds roles that are granted other roles

Finally, we add a table that we want to only be accessed by certain privileges so we add the columns we want plus one for the role that can view this data.

and then we create a new view which uses the data in the role tables plus the current_user() function to determine what data can be displayed.

create or replace view user_student 
    as select s.id, s.name, s.age
        from user_role_privs urp, student s 
       where urp.user=current_user() 
         and urp.role=s.role
       union 
      select s.id, s.name, s.age
        from user_role_privs urp, role_role_privs rrp, student s
       where urp.user=current_user()
         and urp.role=rrp.role_id
         and rrp.granted_role=s.role

Now if your php allows user1 to login, they will select from the view and see the following data – that is Pluto is seen based on the direct role grant and Mickey and Donald because the role of clerk is granted to the role of Manager.

But if user2 logins, They will only see the records directly granted to their role of Clerk which are Mickey and Donald.

So if your application selects data from the user_student role instead of the student table, it would provide read access.

To do write access based on the role, you would probably need to extend this idea to include an edit flag on the role table and only show an edit button and related functionality if the role permitted it.

A role should have access to edit any data it can see so you keep the code simpler by creating more roles if needed. For inserts into the table, you may also need a before insert trigger, to insert a role of the user that created it in the student.role column. You would have to decide if this should be the role with the highest or lowest privileges as this then grants other users access as well.