Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Date: Thu, 13 Oct 2011 22:00:12 +0000 (UTC)
From: "Stefan Seelmann (Commented) (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Message-ID: 
 <333952313.11323.1318543212079.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <580879460.9693.1318521851608.JavaMail.tomcat@hel.zones.apache.org>
Subject: [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
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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