directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Seelmann (Commented) (JIRA)" <>
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
Date Thu, 13 Oct 2011 22:00:12 GMT


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,
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:
>             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:!default.jspa
For more information on JIRA, see:


View raw message