[Grok-dev] Re: grok and complicated permissions

[Martijn Faassen]

Brandon Craig Rhodes wrote:
> I have read PvW's book and also example Grok code, and am not finding
> a complicated enough security scheme for my needs.  It looks like the
> default scheme (which is similar to the one used in Plone 2) involves
> giving actors permissions expressed as strings ('Create mammoth') and
> then saying that certain grok.Views (or, in pure Zope 3, that certain
> object attribute accesses) require that permission.
> 
>  1) I need more interesting rules.  For example, if "Change password"
>     is a permission required to use my "ChangePasswordView", then in
>     my case it will depend on the combination of who is attempting the
>     change and whose account they are acting on.  The rule will be
>     something like: "If you are a campus-wide admin, you can change
>     the password of any account; but if you are department-hired
>     admin, then you can only change the passwords of users who work
>     for your department."
[snip]

You could solve this by using local roles given suitably organized 
object hierarchies. You allow anyone with the 'Change password' 
permission to access the ChangePasswordView. You store these objects per 
department and then give someone a local role (or permission) on the 
department they're allowed to edit.

Alternatively you can go for an entirely new zope security policy. 
Zope's security policy is replacable. zope.app.securitypolicy implements 
the default one, but it is replacable. A bigger task, of course.

>  2) Part of what attracted me to Zope 3, as I read PvW's book, was
>     that objects can be protected rather than views.  I like the idea
>     of saying what can and can't be done to objects themselves.
> 
>     If I have to protect an account from having its password changed,
>     for example, I can restrict access to its "change_pw()" method and
>     know that no present or future View will accidentally get coded in
>     such a way as to let an agent run the method.

This sounds nice in theory. In practice while developing with Zope 3, it 
tended to slow me down enormously, as Zope 3's security policy was to 
make everything private by default. Of course the first five tries while 
developing you'd forget to open exactly those permissions with exactly 
the required permissions. Early on during development you just want to 
see stuff on your screen and not actually worry about permissions yet. 
This is why we deliberately pulled all of this out of Grok. If a 
security system is secure by default but actually frustratingly hard to 
reason about, it won't be secure in the end.

That said, I know there is an interest in seeing this work with Grok 
though. Grok should definitely not be standing in the way of making this 
work (currently its own publication rips off security proxies, and this 
behavior should become optional). Perhaps a security system where 
methods are public by default, and a @grok.require decorator system to 
annotate such methods with permissions, is actually workable. 
Experimentation awaits us.

>     Do we have a story yet for how Grok security, which from what I
>     can tell is built around Views, can be pushed back down on to
>     objects and their attributes?

If you modify Grok's publication and stop it from removing the security 
proxies automatically, you're quite far along already. You'd also need 
to write grokkers that then act on whatever information @grok.require 
leaves behind in the class or module and registers it with Zope 3.

Note that Zope 3's security system is limited; no security checks are 
made for objects returned by a catalog query for instance, or objects 
that you retrieve by getUtility. At the same time it's also pervasive: 
get a security proxy into the wrong parts of your codebase and it will 
tend to gum up the works in frustrating ways.

>  One of the things that I have,
>     actually, enjoyed about Plone is that if you protect a piece of
>     content, then it magically disappears from both its own views and
>     all views of its container (of which there are sometimes two or
>     three that might list or let you rename the object!) for not
>     authorized users, but everything else on each page continues to be
>     displayed for them.  It's neat to be able to create complex views
>     that show a dozen things, and know that one of the dozen will be
>     missing but leave the page functioning if a security setting turns
>     off access to it.

Actually this is something that a security system by itself does not do. 
Plone (or CMF) must somewhere be inspecting the objects permissions and 
not returning these as results. Someone more knowledgeable about Plone 
will be able to tell you where it does this.

As far as I know, you can implement things like this with grok as it 
stands today. While Grok doesn't *automatically* check security on 
underlying objects, just on views, *you* can definitely do so. You could 
for instance write an adapter for containers that only returns those 
objects that the user has some permission for. Mind that this will get 
quite complicated once you enter the domain of catalog queries and such.

Regards,

Martijn