I'm increasingly frustrated with the Zope security management framework, and I'd like to know if there is a way to work around some of my problems, and/or whether this will be addressed in the future. Or, perhaps I'm looking at all this from the wrong perspective. Essentially, I'd like a way to eliminate a role in certain directories. For example, if anonymous users should be granted no access to a "/private" folder, I want to lock down /private and all sub-directories against anonymous access. The only solutions I've found are inadequate. What I've found: * At the root folder, find those permissions which are enabled for the anonymous role, and remove them in /private by de-selecting the "inherit permissions" checkbox and re-enable appropriate roles. * In /private, de-select _all_ "inherit permissions" checkboxes and re-enable appropriate roles. The first is inadequate because of the lack of control over what permissions are enabled for anonymous users at the root folder. If a particular permission is added to the root folder the next day, anonymous users now have a permission in /private which they should not have. The second, besides being extremely tedious and error-prone, removes the flexibility of defining globally what permissions roles should play across all of the server. What am I missing? -- -- John R. Daily jdaily@progeny.com Systems Programmer Progeny Linux Systems Master of the ephemeral epiphany
Essentially, I'd like a way to eliminate a role in certain directories. For example, if anonymous users should be granted no access to a "/private" folder, I want to lock down /private and all sub-directories against anonymous access.
The only solutions I've found are inadequate. What I've found:
* At the root folder, find those permissions which are enabled for the anonymous role, and remove them in /private by de-selecting the "inherit permissions" checkbox and re-enable appropriate roles.
* In /private, de-select _all_ "inherit permissions" checkboxes and re-enable appropriate roles.
The first is inadequate because of the lack of control over what permissions are enabled for anonymous users at the root folder. If a particular permission is added to the root folder the next day, anonymous users now have a permission in /private which they should not have.
How will this permission be added? Who is defining permissions for your site? Are you talking about permissions defined by products your download and install or are you talking about permissions defined by products you create?
The second, besides being extremely tedious and error-prone, removes the flexibility of defining globally what permissions roles should play across all of the server.
What am I missing?
Both of your solutions are essentially the same solution. This solution seems reasonable. It sounds like it may help to define your site's security requirements in writing. You may find that a restructuring of the site's containment structure makes things a lot easier.
The first is inadequate because of the lack of control over what permissions are enabled for anonymous users at the root folder. If a particular permission is added to the root folder the next day, anonymous users now have a permission in /private which they should not have.
How will this permission be added? Who is defining permissions for your site? Are you talking about permissions defined by products your download and install or are you talking about permissions defined by products you create?
I'm not sure why this matters. Let me regroup for a moment, and tell me if I'm mis-understanding the security model. Within any sub-folder, one can do the following to a given role: * Inherit the permission for all roles, but override to grant permission for this role. * Inherit the permission for all roles, including this one. * Do not inherit the permission for all roles, and grant for this role. * Do not inherit the permission, and don't grant. What's missing is this: * Inherit the permission for all roles, but override to deny permission for this role. I can't think of any other security system that makes it difficult to deny access. The only way to deny access at a local level is to duplicate and tweak the security information from the parent node, and duplication of information is anathema to manageability. -John
"John R. Daily" <jdaily@progeny.com> writes:
Within any sub-folder, one can do the following to a given role: <snip> What's missing is this: <snip> I can't think of any other security system that makes it difficult to deny access. The only way to deny access at a local level is to duplicate and tweak the security information from the parent node, and duplication of information is anathema to manageability.
I agree with John that this is a weakness in the current system. I have often found myself wishing for something like tri-state checkboxes (grant/deny/don't care). Would it be correct to say this is not a limitation of the zope security model, but a user interface issue ? -Simon
On Mon, 26 Feb 2001 13:21:18 -0500, "John R. Daily" <jdaily@progeny.com> wrote:
I'm increasingly frustrated with the Zope security management framework, and I'd like to know if there is a way to work around some of my problems, and/or whether this will be addressed in the future. Or, perhaps I'm looking at all this from the wrong perspective.
Essentially, I'd like a way to eliminate a role in certain directories. For example, if anonymous users should be granted no access to a "/private" folder, I want to lock down /private and all sub-directories against anonymous access.
That sounds like the opposite of local roles (which are the ability to grant *extra* roles in a specific context)
The only solutions I've found are inadequate. What I've found:
* At the root folder, find those permissions which are enabled for the anonymous role, and remove them in /private by de-selecting the "inherit permissions" checkbox and re-enable appropriate roles.
* In /private, de-select _all_ "inherit permissions" checkboxes and re-enable appropriate roles.
Thats when we had to do before local roles were added. Is it possible to rearrange your folders so that you use local roles in a /public/ section? Toby Dickenson tdickenson@geminidataloggers.com
The only solutions I've found are inadequate. What I've found:
* At the root folder, find those permissions which are enabled for the anonymous role, and remove them in /private by de-selecting the "inherit permissions" checkbox and re-enable appropriate roles.
* In /private, de-select _all_ "inherit permissions" checkboxes and re-enable appropriate roles.
Thats when we had to do before local roles were added.
Is it possible to rearrange your folders so that you use local roles in a /public/ section?
My current problem revolves around the anonymous user. If I could make 'anonymous' a local role, that would potentially help, although with most web-sites the root of the site should be readable by anonymous, so it's not clear that it's an effective workaround. However, it still doesn't affect what I perceive to be the basic problem: a security system should offer one the ability to deny access, and the only mechanism I can find for doing so in Zope is to duplicate the security information from the parent folder and tweak it. That makes central administration harder and is error-prone. -John
participants (4)
-
Chris McDonough -
John R. Daily -
Simon Michael -
Toby Dickenson