Now the caveat: when you give someone the "Change permissions" permission, you are effectively trusting him as a Manager in his own area. Though he can't affect things outside his area, it is not really possible to actually restrict what he can do in his own area once you've given "Change permissions". This is because he is now free to give himself any permission he wants (in his own folder) if he doesn't already have it.
And that's exactly the problem I see.
If I take away "Create ZSQL Methods" from his home folder but don't take away the security tab, he can put it right back. If I'm using UserDB to authenticate he can just create a Z SQL Method that queries the db for userid's and passwords.
It seems the only way to securely handle all this is to roll your own folder that can't hold Z SQL Methods, or anything else that users don't really need. (Incidentally, if I did this with Z Classes, would there be any performance implications?)
I don't think there would be any real performance hit - but I suspect that it would be painful enough that _I_ wouldn't want to write it...
It is possible that this behavior could be modified in the future (by enforcing some rules whereby a user can only modify roles or permissions that he already has), but some thought would need to go into this to be sure that there is a real need for it and that the behavior is well understood.
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. Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com