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 (Updated) (JIRA)" <ji...@apache.org> on 2011/10/13 18:11:12 UTC

[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

     [ 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