[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

["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