Hi, I have this q'n already a long time in my head and I still don't know the answer to it. It has to do with the security-view. I hope that someone can shed a light on my brains. Why is their an Acquire permission (referred to as acq_perm in following text) checkbox column? In order to change a permission for a certain role, we have to check or uncheck this permission at the roles permission checkbox. However, for this to work we have to uncheck the acq_perm column (because if this one is checked, the permission is taken from parent-folder-objects anyway, the value of the role checkbox doesn't counts at that moment). As a drawback, this means that all roles have to be checked/unchecked, because they don't acquire the permission anymore from one of its parents-folder-objects. Now, why couldn't this be implemented like the following? Isn't this easier to grasp? The Acq_perm column doesn't exists. Assume that acquisition of a permission is always Active. The checkboxes of the role show their actual value (according to the acquisition). Thus if permissionA is checked in the parent-object, permissionA is also checked. If you want, for a certain role that this permission is not given, you uncheck permissionA. The subobject will show an unchecked permissionA box (because it acquires from its parent). In order to give the subobject again the permission, we only have to check permissionA. A) In the first approach we've to uncheck the acq_perm checkbox and have to set the checkbox of every role according to how we want the permission to be handled by that role. B) In the second approach we've to uncheck the permission checkbox of the role(s). Other roles are not effected. Am I missing something here? Is my explenation somewhere wrong? Why does Zope uses the first approach? Which, sounds for me, a little bit more complicated. Thanks for any explanation! Tom Deprez.
Tom Deprez wrote:
Hi,
I have this q'n already a long time in my head and I still don't know the answer to it. It has to do with the security-view. I hope that someone can shed a light on my brains.
Why is their an Acquire permission (referred to as acq_perm in following text) checkbox column?
It allows you to honor permission settings made in containing objects.
In order to change a permission for a certain role, we have to check or uncheck this permission at the roles permission checkbox.
I don't understand this. You can grant permissions to a role locally, regardless of whether you acquire permission settings. If you don't acquire, then the role only gets the permissions you set, otherwise, it *may* get permissions from above.
However, for this to work we have to uncheck the acq_perm column (because if this one is checked, the permission is taken from parent-folder-objects anyway, the value of the role checkbox doesn't counts at that moment).
You don't have to ncheck the acq_perm column if you simply want to grant a permission to a role. You only need to uncheck the acq_perm column if you want to prevent containing objects from granting a permission to other roles.
As a drawback, this means that all roles have to be checked/unchecked, because they don't acquire the permission anymore from one of its parents-folder-objects.
So don't uncheck the acq_perm column.
Now, why couldn't this be implemented like the following? Isn't this easier to grasp?
The Acq_perm column doesn't exists. Assume that acquisition of a permission is always Active. The checkboxes of the role show their actual value (according to the acquisition). Thus if permissionA is checked in the parent-object, permissionA is also checked. If you want, for a certain role that this permission is not given, you uncheck permissionA. The subobject will show an unchecked permissionA box (because it acquires from its parent). In order to give the subobject again the permission, we only have to check permissionA.
The problem with this is that it doesn't recognize changes made to containers later.
A) In the first approach we've to uncheck the acq_perm checkbox and have to set the checkbox of every role according to how we want the permission to be handled by that role.
You don't need to uncheck the acq_perm checkbox unless you want to prevent containers from granting permissions.
B) In the second approach we've to uncheck the permission checkbox of the role(s). Other roles are not effected.
Am I missing something here? Is my explenation somewhere wrong? Why does Zope uses the first approach? Which, sounds for me, a little bit more complicated.
By acquiring permission settings you are allowing containers to grant a permission to a role today or sometime in the future. This allows someone to control permissions in a centralized fashion. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Thanks Jim, for answering my q'n.
In order to change a permission for a certain role, we have to check or uncheck this permission at the roles permission checkbox.
I don't understand this. You can grant permissions to a role locally, regardless of whether you acquire permission settings. If you don't acquire, then the role only gets the permissions you set, otherwise, it *may* get permissions from above.
So, if I understand this correctly : A)Assume I want to remove the View permission from the anonymous role in folder 'private' (just below root-folder). I've to uncheck the view permission for anonymous and also the acquire permission for view (because otherwise anonymous would still have the view permission by acquisition from root) Since acquire permission for view is unchecked, all roles take over the permission set for View at folder 'private' (no acquisition). Assume I had in root a 'RoleA' and permission was set for View. At this moment I have to check the view permission for RoleA. B)Assume I want to give Anonymous the right to 'Add Folders' Then I only have to check the 'Add Folders' permission for Anonymous and the permission will be granted to Anonymous (even, although in the root-folder Anonymous doesn't has the right? Acquisition doesn't takes part, although it is still check for 'Add Folders'?) If above is correct, then I was wrong in my thinking for situation B. But then where stands acquisition for this situation? It is checked for 'Add Folders', so it should get it's permission from 'root' and not from 'private'.
Now, why couldn't this be implemented like the following? Isn't this easier to grasp?
The Acq_perm column doesn't exists. Assume that acquisition of a permission is always Active. The checkboxes of the role show their actual value (according to the acquisition). Thus if permissionA is checked in the parent-object, permissionA is also checked. If you want, for a certain role that this permission is not given, you uncheck permissionA. The subobject will show an unchecked permissionA box (because it acquires from its parent). In order to give the subobject again the permission, we only have to check permissionA.
The problem with this is that it doesn't recognize changes made to containers later.
I was more talking about another view to the permission roles. Iside Zope you would still need to have the acquire permission boolean. However, this would be attached to every role per container. Instead of one acquire permission column, you would have an acquire permission column for every role per container. This would eliminate the things wich happend with RoleA (see above), because the acquire permission is still checked for RoleA for this container. Off course having a second column of checkboxes (acquire permission) would confuse even more. Therefor the proposition of handling the acquire permission automatically behind the scenes. But perhaps this isn't possible when situation 'B' is possible.
By acquiring permission settings you are allowing containers to grant a permission to a role today or sometime in the future. This allows someone to control permissions in a centralized fashion.
Sorry, I don't understand above sentence. ---- Other question: If acquire permission is set for RoleA (in 'private') and RoleA has the 'view permission' in 'Root', then RoleA has the view permission in 'private' (acquisition, not?). However the checkbox at 'view permission' for RoleA is not checked. I it possible to put name next to this checkbox which tells that permission to 'view' for RoleA is acquired from 'root', or just a link which brings us directly to the security view of 'root'. I'm thinking that this would help us a lot when we want to know from where the permission is granted. Then we don't have to check all security views of the parent-containers. Thanks in advance, Tom.
Tom Deprez wrote:
Thanks Jim,
for answering my q'n.
In order to change a permission for a certain role, we have to check or uncheck this permission at the roles permission checkbox.
I don't understand this. You can grant permissions to a role locally, regardless of whether you acquire permission settings. If you don't acquire, then the role only gets the permissions you set, otherwise, it *may* get permissions from above.
So, if I understand this correctly :
A)Assume I want to remove the View permission from the anonymous role in folder 'private' (just below root-folder).
I've to uncheck the view permission for anonymous and also the acquire permission for view (because otherwise anonymous would still have the view permission by acquisition from root)
Right.
Since acquire permission for view is unchecked, all roles take over the permission set for View at folder 'private' (no acquisition).
Only those roles you've checked will have the view permission of acquisition of permission settings is disabled.
Assume I had in root a 'RoleA' and permission was set for View. At this moment I have to check the view permission for RoleA.
Right.
B)Assume I want to give Anonymous the right to 'Add Folders'
Then I only have to check the 'Add Folders' permission for Anonymous and the permission will be granted to Anonymous (even, although in the root-folder Anonymous doesn't has the right?
Right.
Acquisition doesn't takes part, although it is still check for 'Add Folders'?)
Yes and no. Since everyone has the anonymous role, Zope won't bother checking containing folders if anonymous is granted access.
If above is correct, then I was wrong in my thinking for situation B. But then where stands acquisition for this situation? It is checked for 'Add Folders', so it should get it's permission from 'root' and not from 'private'.
You've lost me. If you are saying that granting anonymous a permission makes acquirintg settings for that permission irrelevent, you are right.
Now, why couldn't this be implemented like the following? Isn't this easier to grasp?
The Acq_perm column doesn't exists. Assume that acquisition of a permission is always Active. The checkboxes of the role show their actual value (according to the acquisition). Thus if permissionA is checked in the parent-object, permissionA is also checked. If you want, for a certain role that this permission is not given, you uncheck permissionA. The subobject will show an unchecked permissionA box (because it acquires from its parent). In order to give the subobject again the permission, we only have to check permissionA.
The problem with this is that it doesn't recognize changes made to containers later.
I was more talking about another view to the permission roles. Iside Zope you would still need to have the acquire permission boolean. However, this would be attached to every role per container. Instead of one acquire permission column, you would have an acquire permission column for every role per container. This would eliminate the things wich happend with RoleA (see above), because the acquire permission is still checked for RoleA for this container.
Off course having a second column of checkboxes (acquire permission) would confuse even more. Therefor the proposition of handling the acquire permission automatically behind the scenes. But perhaps this isn't possible when situation 'B' is possible.
Another possibility would be at provide an option to deny access. Then you could deny access to view in example A without affecting RoleA.
By acquiring permission settings you are allowing containers to grant a permission to a role today or sometime in the future. This allows someone to control permissions in a centralized fashion.
Sorry, I don't understand above sentence.
The point is that the acquisition is done dynamically when permissions are checked. Suppose I acquire the permission settings for the "Add Folder" permission. Today, that may mean I acquire the ability for "Owners" to add folders. Tomorrow, someone may also grand "Add Folder" to members. I'll acquire that as well, automatically.
----
Other question:
If acquire permission is set for RoleA (in 'private') and RoleA has the 'view permission' in 'Root', then RoleA has the view permission in 'private' (acquisition, not?).
You cant set the "acquire permission settings" check box for roles. You can only set it for permissions. If the acquire permissions settings is set for the permission "View" in folder "private" and "RoleA" has the "View" permission in the root, then "RoleA" has the permission setting implicitly in folder "private".
However the checkbox at 'view permission' for RoleA is not checked.
Because it is not set here.
I it possible to put name next to this checkbox which tells that permission to 'view' for RoleA is acquired from 'root', or just a link which brings us directly to the security view of 'root'.
That would be useful, as long as people understand that the decoration could change when someone changes a setting up above.
I'm thinking that this would help us a lot when we want to know from where the permission is granted. Then we don't have to check all security views of the parent-containers.
Yes, I agree, that this would be useful. Maybe the security display wouldn't give the source directly but maybe a symbol with alt text that gives the source location and some sort of hyperlink to the same. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
B)Assume I want to give Anonymous the right to 'Add Folders'
Then I only have to check the 'Add Folders' permission for Anonymous and the permission will be granted to Anonymous (even, although in the root-folder Anonymous doesn't has the right?
Right.
Acquisition doesn't takes part, although it is still check for 'Add Folders'?)
Yes and no. Since everyone has the anonymous role, Zope won't bother checking containing folders if anonymous is granted access.
aha, yes! everybody has the anonymous role, so the permissions a certain person has, is the sum of the anonymous permissions and the permission to his/her role (if a role is assigned to the person) mmm. Ok, let's assume we've made a RoleB which is in fact just the same as anonymous and we imply this example on situation B: RoleB doesn't has the permission 'Add Folders' in Root (neither does anonymous). And in private, we want to give RoleB the right to 'Add Folders'. Then I only have to check the 'Add Folders' permission for RoleB and the permission will be granted to RoleB, in 'private'. Even, RoleB doesn't has the right to 'Add Folder' in 'root' and acquire permissions is set in 'private' for 'Add Folder'
If above is correct, then I was wrong in my thinking for situation B. But then where stands acquisition for this situation? It is checked for 'Add Folders', so it should get it's permission from 'root' and not from 'private'.
You've lost me. If you are saying that granting anonymous a permission makes acquirintg settings for that permission irrelevent, you are right.
So, what I don't understand is this (if my assumption with B is correct): In 'private', the acquire permission is checked for 'Add Role'. In 'root', RoleB doesn't has the permission to 'Add Folder'. So, since we set that permission is acquired, RoleB would normally not have the permission to 'Add Folder'. However, in 'private', we've given RoleB the permission to 'Add Folder', so RoleB has the permission 'Add Folder'. Doesn't this breaks the acquire rule? We say that 'Add Role' must be acquired from above, but Zope doesn't looks further than 'private' since 'Add Folder' is given to RoleB in 'private'.
I was more talking about another view to the permission roles. Iside Zope you would still need to have the acquire permission boolean. However, this would be attached to every role per container. Instead of one acquire permission column, you would have an acquire permission column for every role per container. This would eliminate the things wich happend with RoleA (see above), because the acquire permission is still checked for RoleA for this container.
Off course having a second column of checkboxes (acquire permission) would confuse even more. Therefor the proposition of handling the acquire permission automatically behind the scenes. But perhaps this isn't possible when situation 'B' is possible.
Another possibility would be at provide an option to deny access. Then you could deny access to view in example A without affecting RoleA.
So, you mean with 'deny access' a new permission 'deny view'? Sorry, you've lost me here.
By acquiring permission settings you are allowing containers to grant a permission to a role today or sometime in the future. This allows someone to control permissions in a centralized fashion.
Sorry, I don't understand above sentence.
The point is that the acquisition is done dynamically when permissions are checked. Suppose I acquire the permission settings for the "Add Folder" permission. Today, that may mean I acquire the ability for "Owners" to add folders. Tomorrow, someone may also grand "Add Folder" to members. I'll acquire that as well, automatically.
aha, this is again the sum of permissions, not? ie. permission I have today are the sum of permissions of all my roles asigned to me.
----
Other question:
If acquire permission is set for RoleA (in 'private') and RoleA has the 'view permission' in 'Root', then RoleA has the view permission in 'private' (acquisition, not?).
You cant set the "acquire permission settings" check box for roles. You can only set it for permissions.
Yep, you're right here. acquire permissions is for all roles. (I mixed it up with my idea explained above. ie. an acquire permission setting for every role per container.) Sorry.
If the acquire permissions settings is set for the permission "View" in folder "private" and "RoleA" has the "View" permission in the root, then "RoleA" has the permission setting implicitly in folder "private".
However the checkbox at 'view permission' for RoleA is not checked.
Because it is not set here.
It isn't set, because the administrator knows that the view permission is acquired from one of the containers above, thus he didn't needed to set it.
I it possible to put name next to this checkbox which tells that permission to 'view' for RoleA is acquired from 'root', or just a link which brings us directly to the security view of 'root'.
That would be useful, as long as people understand that the decoration could change when someone changes a setting up above.
Yes, but then this name/link would change also not? The name/link would point to the place where Zope stopped it's acquire algoritmen. And this algoritmen stops if Zope knows for sure if the permission is granted or not.
I'm thinking that this would help us a lot when we want to know from where the permission is granted. Then we don't have to check all security views of the parent-containers.
Yes, I agree, that this would be useful. Maybe the security display wouldn't give the source directly but maybe a symbol with alt text that gives the source location and some sort of hyperlink to the same.
Yes, that would be nice. Tom.
participants (2)
-
Jim Fulton -
Tom Deprez