Security Design: Why Pyramid automatically added userid into effective_principals?

[Lingfeng Xiong]

Hi all,
I am suffering a strange authentication problem: when a user with only 'profile' permission tried to access a view  required 'admin' permission, it can pass the permission check and access that view normally.
As you can see, this should not happen because such users have only 'profile' permission and has no 'admin' permission.
After a long investigation, I found the source of the problem:
I return a list of group_id of a user whose belong to in the callback of 'groupfinder'. And in authentication.py line 171, it added 'user_id' into effective principals. I don't know why the author added user_id into effective principals.
I believe, in a common scenario, permissions are attached to group, and store group_id as identifier of permission finders is a good choose. Even in a situation where no group available, we can just return user_id in groupfinder function instead of hardcoding the user_id into effective principals.

[Michael Merickel]

For better or worse, an authentication policy deals in principals, not groups, and Pyramid treats the user_id as a principal. This issue has come up in the past and is documented behavior of the authentication policies in Pyramid. For example, if you are storing the user name as the "user_id", it's possible for someone to name themselves "admin" and gain escalated privileges in your site if your ACLs are setup in such a way. Thus it's recommended that you store an integer for the user id, or something that would not conflict accidentally with your ACLs.

All of this being said, if you do not enjoy this behavior, it is very easy to create your own authentication policy, allowing you full control over what is returned from effective_principals. As an example, I'll point you at the cookbook.

http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/auth/custom.html

HTH,

Michael

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.