Bug 164843

Summary: deleting subtyped attribute value problem.
Product: Red Hat Directory Server Reporter: Noriko Hosoi <nhosoi>
Component: Directory ServerAssignee: Nathan Kinder <nkinder>
Status: CLOSED ERRATA QA Contact: Orla Hegarty <ohegarty>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: ohegarty
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2005-836 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-11-16 21:11:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 152373, 159328, 182343, 182630, 184343, 240316    
Attachments:
Description Flags
CVS Diffs
none
CVS Commit none

Description Noriko Hosoi 2005-08-01 18:49:26 UTC
Description of problem:
An entry has an attribute (attrA) having the same value (valueA) under the
different subtypes (lang-XX):
attrA: valueA
attrA;lang-en: valueA
attrA;lang-ja: valueA
attrA;lang-ja;phonetic: valueA

If you index attrA, they are indexed under one key "valueA" in the index file
attrA.db#.

Then, remove one attribute value, e.g., "attrA;lang-ja: valueA",
which deletes the key "valueA" in the index file attrA.db#.

After the key is deleted, search with the filter "(attrA=valueA)" returns none
even if the attribute values still exist in the entry.

Version-Release number of selected component (if applicable):
Found at HP.  Could be reproduced on 7.1 on RHEL4.

How reproducible:
Every time.

Expected results:
We should consult with RFCs to figure out the right behavior:
1) Multiple same values are allowed under the same attribute type?
   Without subtype, it is NOT allowed.  But how about WITH subtypes?
Lu, Grace R C wrote:
> The ldapmodify with replace is broken, how about the original problem
> that the customer reported? In the case of Mail:xyz
> Mail;lang-ja:xyz
>
> The xyz is removed from mail index database after the mail;lang-ja:xyz
> is removed but the mail:xyz still exists? Is this also a defect? 

dboreham wrote:
> I'm not sure if it's really a different defect.
> If it's the case that the two values shouldn't be allowed anyway, then
> the indexing is behaving as designed. I'll need to check the RFCs
> to figure out how duplicate values in subtypes should be handled.

2) If having the same value is allowed:
attrA: valueA
attrA;lang-en: valueA
What is the right behavior?
Deleting one attribute value "attrA;lang-en: valueA" should delete another
"attrA: valueA" in the entry?
Or deleting one attribute value should not delete the key "valueA" in the index
file attrA.db#?

From the customer's point of view, the last is most preferable.
Here is the original report from HP:
"Lu, Grace R C" <grace.lu> wrote:
> We have a customer asking the following:
> They set mail: xyz 
> And then mail;lang-ja: xyz,

> Then they remove the mail;lang-ja:xyz.

> The mail index database becomes empty, when there is still an copy of
> xyz value in the database.

> This does not happen for
> Mail:xyz
> Mail:xyz
> And remove one mail:xyz.

> The index database can be rebuilt, however, they don't want to do that
> over and over again in working environment.
> Can the problem be fixed easily?

Comment 1 Nathan Kinder 2005-08-03 16:43:53 UTC
RFC 3866, section 2.5 states:

  A client can provide multiple attributes with the same attribute type
  and value, so long as each attribute has a different set of language
  tag options.

This means that the following is allowed:

  attrA: valueA
  attrA;lang-en: valueA

RFC 3866, section 2.6 states:

  Attribute types and language tag options MUST match exactly against
  values stored in the directory.  For example, if the modification is
  a "delete", then if the stored values to be deleted have language tag
  options, then those language tag options MUST be provided in the
  modify operation, and if the stored values to be deleted do not have
  any language tag option, then no language tag option is to be
  provided.

Basically, a delete of an attribute with a subtype must explicitly call out that
subtype.  This means that we need to check if any subtypes with the same value
exist in the entry that you are modifying before removing the key from an index.

Comment 2 Nathan Kinder 2005-08-11 21:56:48 UTC
Created attachment 117663 [details]
CVS Diffs

These changes affect the delete and replace operations when being performed
against an indexed attribute.  They basically compile a list of values whose
indexes need to be removed, and another list of which index values are to
remain.  It putting these lists together, attribute subtypes and multivalued
attributes are taken into account.  These lists are then used to modify the
index.

Comment 3 Nathan Kinder 2005-08-12 21:36:32 UTC
Created attachment 117696 [details]
CVS Commit

Checked into ldapserver.  Reviewed by Rich (thanks!).

Comment 4 Rich Megginson 2005-08-24 20:57:33 UTC
Moved to 7.1 sp 1

Comment 5 Orla Hegarty 2005-10-14 16:22:47 UTC
Verified fixed against all supported platforms - RHEL3, RHEL4, Solaris 9 32 and
54 bit, HP-UX 11i. 

Verification 
Run indexes test plan.

Comment 6 Orla Hegarty 2005-11-01 00:36:22 UTC
*DOCS*
A client can provide multiple attributes with the same attribute type and value,
 only if those attributes are language sub-types

This means that the following is allowed:

  attrA: valueA
  attrA;lang-en: valueA

If that attribute is indexed, performing a delete which explicitly calls out the
attribute language sub-type to be deleted will not remove the index for  the
remaining attribute.


Comment 7 John Ha 2005-11-10 05:58:59 UTC
pasted from release notes:

In Red Hat Directory Server 7.1, indexing of multi-valued attributes with
language subtypes was not handled correctly. This issue has been fixed.

Comment 8 Red Hat Bugzilla 2005-11-16 21:11:20 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-836.html


Comment 9 Nathan Kinder 2006-02-23 19:01:42 UTC
*** Bug 164590 has been marked as a duplicate of this bug. ***

Comment 10 To Ngan 2006-03-14 15:30:49 UTC
Verified DS6.21 SP3 candidates 20060222.1 and 20060310.1 on all platforms.

Comment 11 Chandrasekar Kannan 2008-08-11 23:36:35 UTC
Bug already CLOSED. setting screened+ flag