There are two basic approaches to a permission model that are worth considering. The first is the access control list. In that style of permission system you have concrete lists of information from which you compute whether a given permission exists. The second is the capability model. If you can name the action, you have permission to do it. But you can't name the action without having some existing permission.

A good example of an access control list approach is Unix. Here is that example in detail. Each person belongs to a list of groups. Each item in your system belongs to a user and a group. Each item gets a set of permissions for its owner, permissions for its group, and permissions for the general public. To see if you have a permission, check whether you are the owner, if so you get the owner's permissions. If you are not the owner, see if you belong to the group that owns it, if so you get the group's permissions. Otherwise you get the permissions that the general public has.

Access control lists don't have to be done that exact way. Personally I would tend to implement an access control list for a small application by having the lists be little join tables, and picking a permissioning model that can be modelled as a few joins. Access control lists have a lot to say for them. They are simple to explain, fairly easy to implement, and (at least at first) easy for people to understand.

Capability models take a little adjusting to get used to, but they have many advantages. Much about what they are, how they compare to access control lists, and some notes on how to implement them can be found in the introductory essays for the EROS operating system. (Which is a capability based operating system.) But still a simpler explanation seems warranted.

A capability permission model is very similar to an OO model of programming. You have opaque capabilities (think objects) through which you can make requests (think method calls). Without the capability (object) there is no way to make the request. In order to get the capability, you need to ask for it from a constructor. That constructor will look at the permission that it was handed and make its own decision about whether or not to give you that capability. The actual permission system is implicit in the constructor.

There are many advantages to a capability system. The first is that if your overall architecture is already OO, the capability model of doing things maps well into how it is already structured. You can essentially add a security system for negligable energy spent in checks. Another advantage to a capability system is that it is much more flexible and finer grained. If a specific subsystem needs to have a more detailed permission system than you originally planned for, it can. Very easily.

But the big win is what is called the Confused Deputy Problem. In this problem, think of the permission system as a deputy, constantly regulating what you can do and why you can do it. Now you may have multiple different reasons for why you should have permission to do a particular action. For instance you may have write permission for some control files because you need to be able to communicate between different sessions. You may have write access to project files because they are projects you are working on. And now what happens if the user asks you to treat a control file as a project file? Well they ask the program to do it, the program did not check and so asks the OS to do it, the OS looks, finds that you can (because it is something you need to do for internal needs), and goes ahead and wipes them out.

Oops.

The cause of the problem is that your deputy who is keeping track of what you can do, has not kept track of why you are allowed to do it. A request issued for one reason is granted because of a permission issued for an unrelated reason, and something that shouldn't happen does. But this doesn't happen in a capability system! Why not? Well in a capability system if you need to have different sets of permissions for two kinds of actions, you issue capabilities for each kind of action. Now when you ask to exercise your capabilities to handle project files to write to a control file, you fail. It does not matter that your program is theoretically capable of the action, it figures out that users should not be deleting your control files and won't let it happen.

Now I am a person with a lot of math background. One thing that background has taught me is that patterns tend to repeat. Often they will repeat in places that look different and have different names attached. But find the connections between them and you will learn a lot.

And so it is with the difference between ACLs and capability systems. Fundamentally any ACL permission is based on global data. Outside lists, and a small bit of global data. The best scoping you can do, and even that takes work, is to do like suid programs do and switch between a few global roles. By contrast any capability system permissions based on private data which is properly scoped and passed into the permission decisions. The confused deputy problem is just the classic problem with global variables, as it manifests in a permission problem. Changes to global data done for one reason interact with actions in an unrelated part of your program, leading to some form of grief. Properly scope your permission to just the right set of requests, and the problem goes away.

So as an ideal, a capability system is better than an ACL system. It also happens to fit extremely well with an OO system (just name your objects "capabilities" and hide all of the permission decisions behind method calls). However if you don't have a heavily OO system, then a capability system is probably more work than it is worth to implement. But be aware that there are types of problems you will have to live with in an ACL system that capability systems avoid, and there are problems which capability systems can solve that ACL systems simply cannot. (Section 4.2 of this paper gives a number of examples, along with explanations of how to solve them in a capability system.)