[Grok-dev] Re: grok and complicated permissions

[Wichert Akkerman]

Previously Martijn Faassen wrote:
> 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.

It's a special catalog index that indexes which roles, users and groups
have view permission on the object. 

Wichert.

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.