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.