You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Pierre-Arnaud Marcelot (Created) (JIRA)" <ji...@apache.org> on 2011/10/13 18:04:11 UTC
[jira] [Created] (DIRSTUDIO-744) The strategy used when deleting
the last attribute value causes issues in the case when ACLs/ACIs hides and
forbid access to other values
The strategy used when deleting the last attribute value causes issues in the case when ACLs/ACIs hides and forbid access to other values
-----------------------------------------------------------------------------------------------------------------------------------------
Key: DIRSTUDIO-744
URL: https://issues.apache.org/jira/browse/DIRSTUDIO-744
Project: Directory Studio
Issue Type: Bug
Components: studio-ldapbrowser
Affects Versions: 1.5.3
Reporter: Pierre-Arnaud Marcelot
Assignee: Pierre-Arnaud Marcelot
Fix For: 2.0.0
This issue has been reported to me by Daniel Pluta, who I met at LDAPCon 2011.
Here's a copy of the bug he described me and which i've been able to reproduce with OpenLDAP.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
ADS causes a problem when I want to delete a value from a multi-value attribute (here e.g. member) in case the following ACLs are active:
access to dn.base="ou=groups,dc=foo,dc=bar" attrs=children
by users read
by * none
access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,cn,description
by users read
by * none break
access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,member
by dnattr=member selfwrite
by * none
Based on these ACL each user that is a member of a group entry seems to
be just the only member of these group (from the user's point of view,
in case the user accesses the group's member attribute by read). When
using Apache Directoy Studio to delete this only/single/last group
member ("right click --> delete value") this results in a "to all value" operation, instead of a "to value memberDN" operation.
=> acl_mask: access to entry "cn=test,groups,dc=foo,dc=bar", attr
"member" requested
=> acl_mask: to all values by "cn=user,ou=users,dc=foo,dc=bar", (=0)
It seems to me that this "to all values ..." appears to be a bug in ADS, where the client (ADS) tries to be more clever than needed.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DIRSTUDIO-744) The strategy used when deleting
the last attribute value causes issues in the case when ACLs/ACIs hide and
forbid access to other values
Posted by "Pierre-Arnaud Marcelot (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pierre-Arnaud Marcelot updated DIRSTUDIO-744:
---------------------------------------------
Summary: The strategy used when deleting the last attribute value causes issues in the case when ACLs/ACIs hide and forbid access to other values (was: The strategy used when deleting the last attribute value causes issues in the case when ACLs/ACIs hides and forbid access to other values)
> The strategy used when deleting the last attribute value causes issues in the case when ACLs/ACIs hide and forbid access to other values
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRSTUDIO-744
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-744
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.3
> Reporter: Pierre-Arnaud Marcelot
> Assignee: Pierre-Arnaud Marcelot
> Fix For: 2.0.0
>
>
> This issue has been reported to me by Daniel Pluta, who I met at LDAPCon 2011.
> Here's a copy of the bug he described me and which i've been able to reproduce with OpenLDAP.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> ADS causes a problem when I want to delete a value from a multi-value attribute (here e.g. member) in case the following ACLs are active:
> access to dn.base="ou=groups,dc=foo,dc=bar" attrs=children
> by users read
> by * none
> access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,cn,description
> by users read
> by * none break
> access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,member
> by dnattr=member selfwrite
> by * none
> Based on these ACL each user that is a member of a group entry seems to
> be just the only member of these group (from the user's point of view,
> in case the user accesses the group's member attribute by read). When
> using Apache Directoy Studio to delete this only/single/last group
> member ("right click --> delete value") this results in a "to all value" operation, instead of a "to value memberDN" operation.
> => acl_mask: access to entry "cn=test,groups,dc=foo,dc=bar", attr
> "member" requested
> => acl_mask: to all values by "cn=user,ou=users,dc=foo,dc=bar", (=0)
> It seems to me that this "to all values ..." appears to be a bug in ADS, where the client (ADS) tries to be more clever than needed.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRSTUDIO-744) The strategy used when deleting
the last attribute value causes issues in the case when ACLs/ACIs hide and
forbid access to other values
Posted by "Stefan Seelmann (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126993#comment-13126993 ]
Stefan Seelmann commented on DIRSTUDIO-744:
-------------------------------------------
I think the specific case for delting the whole attribute was to support deletion of attributes that lack a equality matching rule. An example is facsimileTelphoneNumber, when you try to delete the specific value most servers complain that no equality matching rules exists.
There were multiple issues regarding this and the result was that we now check if a matching rule exists, additionally we allow the user to override some behaviour in the edit options tab of the connection properties. But that's not enough.
I think the CompoundModification class is not the right place to fix the problem as it only changes the internal model. The right place should be in module ldapbrowser.core, class org.apache.directory.studio.ldapbrowser.core.utils.Utils, method computeDiff(IEntry, IEntry). It computes the difference in LDIF format that is used to create the LDAP request.
I'll take a look at this code at the weekend. I'm shocked that I wrote that much code without test cases, I'm really ashamed.
> The strategy used when deleting the last attribute value causes issues in the case when ACLs/ACIs hide and forbid access to other values
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRSTUDIO-744
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-744
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.3
> Reporter: Pierre-Arnaud Marcelot
> Assignee: Pierre-Arnaud Marcelot
> Fix For: 2.0.0
>
>
> This issue has been reported to me by Daniel Pluta, who I met at LDAPCon 2011.
> Here's a copy of the bug he described me and which i've been able to reproduce with OpenLDAP.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> ADS causes a problem when I want to delete a value from a multi-value attribute (here e.g. member) in case the following ACLs are active:
> access to dn.base="ou=groups,dc=foo,dc=bar" attrs=children
> by users read
> by * none
> access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,cn,description
> by users read
> by * none break
> access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,member
> by dnattr=member selfwrite
> by * none
> Based on these ACL each user that is a member of a group entry seems to
> be just the only member of these group (from the user's point of view,
> in case the user accesses the group's member attribute by read). When
> using Apache Directoy Studio to delete this only/single/last group
> member ("right click --> delete value") this results in a "to all value" operation, instead of a "to value memberDN" operation.
> => acl_mask: access to entry "cn=test,groups,dc=foo,dc=bar", attr
> "member" requested
> => acl_mask: to all values by "cn=user,ou=users,dc=foo,dc=bar", (=0)
> It seems to me that this "to all values ..." appears to be a bug in ADS, where the client (ADS) tries to be more clever than needed.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRSTUDIO-744) The strategy used when deleting
the last attribute value causes issues in the case when ACLs/ACIs hides and
forbid access to other values
Posted by "Pierre-Arnaud Marcelot (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126685#comment-13126685 ]
Pierre-Arnaud Marcelot commented on DIRSTUDIO-744:
--------------------------------------------------
As we've noticed with Daniel, it seems in that particular case that Studio tries to be more clever than it should be and removes the whole attribute based on the fact that on its side, the deleted value was the last remaining one and therefore the full attribute itself has to be removed.
I debugged this in the code and the part of code deleting the whole attribute is located in the 'org.apache.directory.studio.ldapbrowser.core.utils.CompoundModification' class.
Between lines 151 to 154, the following code is responsible for the whole attribute removal:
151: if ( attribute.getValueSize() == 0 )
152: {
153: attribute.getEntry().deleteAttribute( attribute );
154: }
I've commented it and it seems to fix the issue without creating any particular side effect I could notice.
@Stefan: Do you remember any specific case where this code might be needed or do you think we can simply get rid of it?
> The strategy used when deleting the last attribute value causes issues in the case when ACLs/ACIs hides and forbid access to other values
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRSTUDIO-744
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-744
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.3
> Reporter: Pierre-Arnaud Marcelot
> Assignee: Pierre-Arnaud Marcelot
> Fix For: 2.0.0
>
>
> This issue has been reported to me by Daniel Pluta, who I met at LDAPCon 2011.
> Here's a copy of the bug he described me and which i've been able to reproduce with OpenLDAP.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> ADS causes a problem when I want to delete a value from a multi-value attribute (here e.g. member) in case the following ACLs are active:
> access to dn.base="ou=groups,dc=foo,dc=bar" attrs=children
> by users read
> by * none
> access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,cn,description
> by users read
> by * none break
> access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,member
> by dnattr=member selfwrite
> by * none
> Based on these ACL each user that is a member of a group entry seems to
> be just the only member of these group (from the user's point of view,
> in case the user accesses the group's member attribute by read). When
> using Apache Directoy Studio to delete this only/single/last group
> member ("right click --> delete value") this results in a "to all value" operation, instead of a "to value memberDN" operation.
> => acl_mask: access to entry "cn=test,groups,dc=foo,dc=bar", attr
> "member" requested
> => acl_mask: to all values by "cn=user,ou=users,dc=foo,dc=bar", (=0)
> It seems to me that this "to all values ..." appears to be a bug in ADS, where the client (ADS) tries to be more clever than needed.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRSTUDIO-744) The strategy used when deleting
the last attribute value causes issues in the case when ACLs/ACIs hide and
forbid access to other values
Posted by "Pierre-Arnaud Marcelot (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSTUDIO-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127332#comment-13127332 ]
Pierre-Arnaud Marcelot commented on DIRSTUDIO-744:
--------------------------------------------------
I was pretty sure there was a valid reason for this code to specifically request the deletion of the whole attribute.
Thanks for these insights.
> The strategy used when deleting the last attribute value causes issues in the case when ACLs/ACIs hide and forbid access to other values
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRSTUDIO-744
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-744
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.3
> Reporter: Pierre-Arnaud Marcelot
> Assignee: Pierre-Arnaud Marcelot
> Fix For: 2.0.0
>
>
> This issue has been reported to me by Daniel Pluta, who I met at LDAPCon 2011.
> Here's a copy of the bug he described me and which i've been able to reproduce with OpenLDAP.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> ADS causes a problem when I want to delete a value from a multi-value attribute (here e.g. member) in case the following ACLs are active:
> access to dn.base="ou=groups,dc=foo,dc=bar" attrs=children
> by users read
> by * none
> access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,cn,description
> by users read
> by * none break
> access to dn.onelevel="ou=groups,dc=foo,dc=bar" attrs=entry,member
> by dnattr=member selfwrite
> by * none
> Based on these ACL each user that is a member of a group entry seems to
> be just the only member of these group (from the user's point of view,
> in case the user accesses the group's member attribute by read). When
> using Apache Directoy Studio to delete this only/single/last group
> member ("right click --> delete value") this results in a "to all value" operation, instead of a "to value memberDN" operation.
> => acl_mask: access to entry "cn=test,groups,dc=foo,dc=bar", attr
> "member" requested
> => acl_mask: to all values by "cn=user,ou=users,dc=foo,dc=bar", (=0)
> It seems to me that this "to all values ..." appears to be a bug in ADS, where the client (ADS) tries to be more clever than needed.
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira