Roles and permissions: a good approach in defining permissions?

Question

My application has users and administrators. The administrators split into two: super-admin and limited-admin. The super gets all permissions while the limited can be configured to inherit just the admin permissions that are specifically needed.

I am thinking to define my permissions the following way. Any user permission has an administrator permission:
User:
- post_create
- post_update
- post_delete

Administrator:
- administrator_post_create
- administrator_post_update
- administrator_post_delete

Is this a good approach? Should I rather assign to an Admin all the users permissions and then another one like 'administrator_post_manage_all' which bypasses the ownership check and allows an admin to make modification?

Edit
The following rules must be satisfied:

Only some users can create, update, delete posts; however, they must be the owners of the post to update, delete. Every user of the application should be able to read posts. My administrators should be able to update and delete any user's post.

Answer 1

I've been dealing with these authorization issues in a dozen of softwares ago, and along the way I found this to be the best solution:

• Permissions shall reflect the events (or requirements) of the system;
• Users can be assigned to specific permissions;
• Just use 2 single permissions for CRUD operations by entity - Read and Modify;

CRUD operations: I've never faced a situation that a user can, for example, delete or update an entity but can't create it, so if the user can modify an entity, it is intended that he can create it, update it and delete it.

But according to your requirements, users can read any post and administrators can update/delete posts of other users, so I'd model the permissions this way:

• post_modify -> Users can create, update and delete posts;
• post_modify_others -> Users can update and delete posts of other users;

The most important here is that the semantic and meaning of the permissions are totally aligned to your requirements, which makes implementation easier.

So, administrators would be assigned to post_modify and post_modify_others permissions, while users would be assigned to post_modify permission only.

User groups : I usually store users and its permissions in an specific table, but if the number of users and permissions start to grow, it is a good idea to create another table to link users and permissions (for example, user group) in order to make management easier. So you'd have 2 groups - Administrator and Users - and you'd assign users to these groups, according to their roles in the system, and permissions would be assigned per group and not per users.

Answer 2

Then I would suggest you think about a general data model for storing the permissions that can handle more complex situations in the future. This answer has a good abstraction https://stackoverflow.com/a/10311479/329496 using a table for permissions, another to link roles to permissions, and another to link users to roles, and another to giving permissions directly to users. You could choose to use that data model and manually insert rows into the tables and work out the queries to load which users have what permissions. Then if your application gets more complex you can add more rows without having to change your queries.