[z3-five] Re: Security and Five

[Philipp von Weitershausen]

Martijn Faassen wrote:

>>> We should make sure that everything that we *don't* explicitly set in 
>>> ZCML is actually forbidden. I don't know what Zope 3 does if you 
>>> supply a page and don't set a permission; the permission attribute is 
>>> not required. I imagine it falls back to some default permission in 
>>> that case.
>>
>> Nope, it doesn't. We just discovered a "bug" in the metadirective 
>> interfaces. 'permission' *is* required on all browser:page[s] 
>> directives, probably also for zope:view and browser:view. I will fix 
>> this in Zope3 tonight.
> 
> So what will the fix entail? Making it required?

Indeed. I've tried providing a <browser:page> w/o a permission. The 
result was that the ZCML handler broke; I *should* have gotten an error 
from the zope.configuration machinery telling me that I didn't provide 
permission.

>> also, we might want to get rid of metadirectives.py and import from 
>> zope.app.component etc. directly. I think having well-defined and 
>> limited dependencies to zope.app packages is not only ok but 
>> preferrabl since we don't want to reimplement everything ourselves, 
>> especially not interfaces!
> 
> 
> Agreed, we need to catalog what can be reused from Zope 3. Not 
> everything easily code before, as I was kicking out some security 
> related stuff. Since we're now implementing this at least in part, 
> matters might change.

But the question is whether we should, for example, have our own 
Permission implementation, or interface for that matter; they're not big 
things, but as we say in German: Small animals make crap, too.

>> Now that I've discovered the bug in Zope3, i think it would be even 
>> more important to rely on Z3. Otherwise I'd now have to fix the bug in 
>> Five as well. Would anyone object using imports from zope.app....?
> 
> We're already doing so to support ZPT, so no objections to doing that 
> more. We will need a process to keep track on what exactly we depend, 
> but for now we depend on all of Z3 anyway (at least what's released), 
> which is simplest. :)

I propose to use the dependency tool (Zope3/utilities/finddeps.py). Put 
the output in a DEPENDENCIES.cfg and Five is half-way installable and 
packagable through fdrake's packaging tool!

>>> I was happy to see Philipp define a bunch of permissions. On the 
>>> naming of the permissions, I think we should not use 'zope' but 
>>> 'zope2' as a prefix in Five, as this makes it easy to avoid 
>>> accidental name clashes with permissions that are truly Zope 3 
>>> native. This is important when porting code back and forth; something 
>>> needs to change anyway and it's good to make it not work 
>>> 'accidentally'. Is there anything in the system now that depends on 
>>> the prefix being zope instead of zope2?
>>
>>
>> I don't think so. I don't feel strongly about it the prefix, so 
>> 'zope2' would be fine with me.
> 
> Okay, then I'll look into changing that, unless Sidnei has some comments 
> there as he did the security implementation. Perhaps there's some 
> dependency on zope.Public or somesuch that we're not yet aware of.

zope.Public has a special meaning in the Zope3 security machinery. It is 
synonymous with a <allow> and a special checker instead of the 
permission checker gets used.
We should probably do this the same way with zope2.Public, which should 
mean security.declarePublic(...). I'm sure it is already handled this way :)

> I'd also like to look into the (mis)use of the 'title' attribute to 
> define the Zope 2 permission name. Do we want to continue this or come 
> up with our own attribute itself? If so, what will happen to title?

I agree with Sidnei: I don't see a misuse. Zope uses descriptive strings 
as permissions which are titles in the Zope3 sense. We're just giving 
these titles an id now. Makes perfect sense to me.

Philipp