Permissions - why this setup?

[Misterer]

Hello,

While reading through the checkbox manual and the additional document describing the permission system a question comes to mind: since certain permissions that are set in roles do not guarantee that a user will be able to act accordingly (for example, a Survey Administrator won't necessarily be able to edit all surveys), why have them in roles at all? You still need to allow these permissions in each object's ACL - so why not set the permissions ONLY there? I imagine generic permissions that cannot be applied to any specific object (such as "create survey") could be set in roles, but why have "edit survey" in any role when it doesn't really allow any editing without explicit change in a survey's ACL? I'm wondering if this complexity is really neccessary at all.

Of course, I may be missing some security scenarios which are made possible by your system. If that is the case - could you please describe them? I'm just wondering what would this (more complex) permission system buy us compared to simpler approaches (such as the one I described above).

Thanks.

[pwiesner]

I agree that the security model is complex and it is something we are always looking to improve on.

Can you clarify the security model you described. Are you suggesting:

1 - A system where being in a role gates access to resources. For example being a survey administrator would grant a user the right to edit every survey in the product.

2 - A system where roles do not exist. Instead only permissions are used to gate access to resources.

3 - Something else entirely.

[Misterer]

Well, I'm not really suggesting anything. I'm just trying to figure out why you have the permission system set the way you do. I don't see much use of roles if they don't really grant anything and I still have to use ACL for each object to set the permissions. What's the point of "edit survey" permission granted by the role if it doesn't really grant this access and I STILL have to go and set the same in ACL?

[pwiesner]

I thought you were asking what advantage our security model offered over the model you described. I asked for clarification because I did not complete understand your scenario. It sounds like I misunderstood your initial question.

Roles control which sections of the product a user can access. In order to access administrative pages you need to be in the appropriate administrative role. Additionally, roles control which permissions a given user can be granted.

I believe the current security model was introduced in Ultimate Survey 3.0, which was released well over five years ago. I was not working here at the time but I will check with a senior developer to see if he has anything to add.