#48840 A MOD with multiple modifications can be rejected (20), although it should be accepted
Closed: wontfix None Opened 7 years ago by tbordaz.

Freeipa 4.3.1

389-ds: master

Test case:

Create a freeipa-server (or a standalone instance)

# create a user with 'givenname: foo'
ipa user-add --first=foo --last=bar fbar
-----------------
Added user "fbar"
-----------------
  User login: fbar
  First name: foo
  Last name: bar
  Full name: foo bar
  Display name: foo bar
  Initials: fb
  Home directory: /home/fbar
  GECOS: foo bar
  Login shell: /bin/sh
  Kerberos principal: fbar@<real>
  Email address: fbar@<domain>
  UID: 1080000003
  GID: 1080000003
  Password: False
  Member of groups: ipausers
  Kerberos keys available: False


ldapsearch -LLL -D "cn=directory manager" -w ... -b "cn=users,cn=accounts,SUFFIX" uid=fbar givenname sn
dn: uid=fbar,cn=users,cn=accounts,SUFFIX
givenname: foo
sn: bar

ipa user-mod fbar --first=Foo
ipa: ERROR: Type or value exists:

#audit log
dn: uid=fbar,cn=users,cn=accounts,SUFFIX
result: 20
changetype: modify
add: givenName
givenName: Foo
-
delete: givenName
givenName: foo

Note the if the order of the modification, deletes the current value before setting the new one, the MOD succeeds

ldapmodify -D "cn=directory manager" -w ...
dn: uid=fbar,cn=users,cn=accounts,SUFFIX
changetype: modify
add: givenName
givenName: Foo
-
delete: givenName
givenName: foo

modifying entry "uid=fbar,cn=users,cn=accounts,SUFFIX"
ldap_modify: Type or value exists (20)

ldapmodify -D "cn=directory manager" -w ...
dn: uid=fbar,cn=users,cn=accounts,SUFFIX
changetype: modify
delete: givenName
givenName: foo
-
add: givenName
givenName: Foo

modifying entry "uid=fbar,cn=users,cn=accounts,SUFFIX"


# the audit log is
dn: uid=fbar,cn=users,cn=accounts,SUFFIX
result: 20
changetype: modify
add: givenName
givenName: Foo
-
delete: givenName
givenName: foo
-
...



dn: uid=fbar,cn=users,cn=accounts,SUFFIX
result: 0
changetype: modify
delete: givenName
givenName: foo
-
add: givenName
givenName: Foo
-

According to https://www.ietf.org/rfc/rfc4511.txt 4.6:

     A list of modifications to be performed on the entry.  The
     entire list of modifications MUST be performed in the order they
     are listed as a single atomic operation.  While individual
     modifications may violate certain aspects of the directory schema
     (such as the object class definition and Directory Information Tree
     (DIT) content rule), the resulting entry after the entire list of
     modifications is performed MUST conform to the requirements of the
     directory model and controlling schema [RFC4512].

I did tests with SunDSEE7 and openldap 2.4.40,

on both products the behaviour is the same as in 389, the mod in the order add/delete is rejected, the mod in the order delete/add succeeds

Per weekly meeting:

Close this (we behave the same as OpenLDAP and SunDS)
RHDS always returned this failure. This is a problem of freeipa that incorrectly order the modifications.

This is not invalid, just wontfix (see comment:1).

Metadata Update from @nhosoi:
- Issue set to the milestone: 0.0 NEEDS_TRIAGE

7 years ago

Metadata Update from @vashirov:
- Issue set to the milestone: None (was: 0.0 NEEDS_TRIAGE)

4 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1900

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Invalid)

3 years ago

Login to comment on this ticket.

Metadata