[Zope] Zope and security.

[Otto]

Brian Lloyd wrote:
> 
[big snip]
> > That would probably wouldn't solve the problem, unless you acquisition
> > were involved.  Otherwise you could easily circumvent it by creating a
> > new folder and doing whatever you please there.
> 
> It _would_ use acquisition (it would have to - the security model
> is predicated on it). It would basically be a refinement of the
> current general design, where access control is tightened via a
> cumulative effect as you go down the hierarchy. The essence of the
> refinement would be that you can never give out what you don't already
> have through that cumulative process. Creating a new folder wouldn't
> get around this, because you still can't delegate (or give to yourself)
> what you don't already have.
> 
> For example, I could give Fred the "Owner" local role in his
> Folder, and at the top of the site (above his area and inaccessible
> to him) I could give "Owner" all permissions _except_ "Create ZSQL
> Methods". When Fred went to the Security tab of his Folder (or any
> sub object), he *wouldn't even see that permission listed*, because
> since he doesn't have it, he can't give it. The same would apply to
> local roles - he could only give people those local roles that he
> already has in his area.

(Been a busy week, finally catching up on mail. :)

That would probably solve the problem, but you're right it would take
some serious thought to do it right.

Some other thoughts on how to manage it:

* an extra bit that dictates whether a role can change a permission
(slightly different than your suggestion, since I can force a permission
'on') basically expands "Change Permissions" to each and every
permission.

* put the authentication in the object creation code. This could be
easilly built into existing Zope sites and feels like the "Right Thing"
to me.  If an object doesn't want to be created, why should it?

I'm sure I'll think of more.....

			-Otto.