I've come onto a new a project and the permissions are done with an allow and a deny option for every permission. Until now i've only ever seen/build allow only permissions.

What is the advantage of this? It seems to introduce extra complexity for developer as well as enduser.

The only situation i could think of that an Allow/Deny design can handle, that a Allow-Only can not is the following.

Role has a permission: AllowX = true and DenyX = false. User has an empty permission.

In an allow-Only design you cannot add an empty permission to the user as only AllowX exists, so the "empty" user scoped permission (where it says AllowX = false) would override the role scoped permission.

But there are obviously many ways to handle this. Just dont add an empty user permission by default. Make the default user permission an aggregate of the role permissions.

However you see this Allow/Deny model in windows and probably a lot bigger apps. Whats the reason?

2 Answers 2


If you only ever deal with individual users, individual assets and individual permissions, you probably don't need a deny permission.

As soon as you deal with groups, of users, assets or permissions, deny permissions make things much easier to manage. Some slightly made up examples:

Allow (Users = *, Table = *, Permission = Read)
Deny (Users = *, Table = credit_card_numbers, Permission = Read)


Allow (Users = TeamA_Group, Table = teama_*, Permission = Write)
Deny (Users = TeamAProjectManager, Table = teama_*, Permission = Write)


Allow (Users = TeamA_Group, Table = teama_*, Permission = *)
Deny (Users = TeamA_Group, Table = teama_*, Permission = Delete)

without a deny permission in those cases, you'd have to individually give read permission on every other table, to each member of TeamA other than the project manager, or to every non-delete permission. That's both error prone and needs action every time a new table / team member / permission arrives as opposed to just doing the right thing by default.


Allow/Deny allows hierarchical permissions, commonly demonstrated by files and folders.

ie UserA can read and write the contents of /folder but is denied write for folder/file1

In this way, where there are many files in the folder I can express the permissions more succinctly than an Allow for every file plus a deny of the file1.

However! It's a flawed system. As the number of groups and objects increase the overlapping permissions become impossible to manage. In order to work out whether a user has a permission or not you have to calculate the combination of groups. No problem for a computer, but difficult for a human.

You can achieve the same complexity with a single layer permission system and "Roles". Each role gets a combination of single layer permissions, which don't change and users are assigned to roles.

Because the permissions are static and require no calculation they are easily understood, and because users are assigned to these roles rather than each having their own combination of permissions you can easily state who can do what.

  • What's the difference between a role and a group?
    – 8bittree
    Feb 21 at 18:35
  • A role is a set of permissions and a group is a set of users. so i might say everyone in the group "AuditorTeamNewYork" is in the Role "Auditor" which has permissions "Read Audit"
    – Ewan
    Feb 22 at 16:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.