Bug 305131 - Server rejects an empty modify operation
Summary: Server rejects an empty modify operation
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.1.0
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 389_1.2.7 639035
TreeView+ depends on / blocked
 
Reported: 2007-09-25 14:34 UTC by Miloslav Trmač
Modified: 2015-12-07 16:34 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-12-07 16:34:08 UTC
Embargoed:


Attachments (Terms of Use)
Patch (2.21 KB, patch)
2010-10-19 15:14 UTC, Nathan Kinder
nkinder: review?
rmeggins: review+
Details | Diff

Description Miloslav Trmač 2007-09-25 14:34:00 UTC
Version-Release number of selected component (if applicable):
fedora-ds-base-1.1.0-1.2.fc7

Note: I'm not an LDAP expert.

An empty LDAP modify operation (e.g. running ldapmodify, entering a DN and an
empty line) fails.  RFC 2251 p4.6 describes the list of modifications as a
SEQUENCE OF, which seems to allow an empty sequence.

Therefore, shouldn't the empty LDAP modify operation succeed?

Comment 1 Rich Megginson 2007-09-25 22:10:26 UTC
Yes, but some caveats apply.
http://www.mail-archive.com/ldap@umich.edu/msg00605.html

Comment 4 Rich Megginson 2009-04-09 17:08:20 UTC
This falls under the category of RFC correctness.
This is related to
Bug 249327 -  Should only update modifyTimestamp/modifiersName on MODIFY ops
That is - should an empty mod op also update these attrs - sort of like how the *nix "touch" command can be used to update the timestamp of a file.

Comment 5 Rich Megginson 2009-04-09 17:27:07 UTC
See also bug 450742

Comment 6 Rich Megginson 2009-04-09 17:27:34 UTC
(In reply to comment #5)
> See also bug 450742  

no - bug 453756

Comment 8 Nathan Kinder 2010-10-19 15:14:22 UTC
Created attachment 454373 [details]
Patch

Comment 9 Nathan Kinder 2010-10-19 15:30:06 UTC
Pushed to master.  Thanks to Rich for his review!

Counting objects: 15, done.
Delta compression using 2 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 793 bytes, done.
Total 8 (delta 6), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   f4c6760..6160200  master -> master

Comment 10 Amita Sharma 2011-04-07 13:51:55 UTC
Hi Nathen,

My understanding for this bug is :
1. Need to test :
[root@rhel61-ds90-amita scripts]# ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 << EOF
> dn:
> EOF
modifying entry ""
Should not give any error.

2. Then I should check for the attributes modifyTimestamp/modifiersName which can be updated using Modify Operation.

I request you to please verify this information and please also add your comments. Like whether it should be tested for user or group and only for these two : modifyTimestamp/modifiersName or more ........ ?

Comment 11 Nathan Kinder 2011-04-11 15:30:23 UTC
(In reply to comment #10)
> Hi Nathen,
> 
> My understanding for this bug is :
> 1. Need to test :
> [root@rhel61-ds90-amita scripts]# ldapmodify -x -h localhost -p 389 -D
> "cn=Directory Manager" -w Secret123 << EOF
> > dn:
> > EOF
> modifying entry ""
> Should not give any error.
> 
> 2. Then I should check for the attributes modifyTimestamp/modifiersName which
> can be updated using Modify Operation.
> 
> I request you to please verify this information and please also add your
> comments. Like whether it should be tested for user or group and only for these
> two : modifyTimestamp/modifiersName or more ........ ?

You really should be testing this against actual entries instead of the root DSE (the "" DN).  The type of entry doesn't matter, so just perform an empty modify operation against a test user entry.  Just check if modifyTimestamp and modifiersName are updated.

Comment 12 Amita Sharma 2011-04-12 07:17:42 UTC
Steps for verification
=======================
1)
ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 << EOF
dn: uid=amita,dc=example44,dc=com
changetype: add
objectClass: top
objectClass: person
objectClass: inetorgperson
sn: amita
cn: amita
userPassword: redhat
EOF

2)
ldapsearch -x -h localhost -p 1389 -D "cn=Directory Manager" -w Secret123 -b "dc=example44,dc=com" -s sub "(objectclass=*)" creatorsName createTimestamp modifiersName modifyTimestamp
# amita, example44.com
dn: uid=amita,dc=example44,dc=com
creatorsName: cn=directory manager
createTimestamp: 20110412062039Z
modifiersName: cn=directory manager
modifyTimestamp: 20110412062039Z

3)
ldapmodify -x -h localhost -p 1389 -D "uid=amita,dc=example44,dc=com" -w redhat << EOF
dn: uid=amita,dc=example44,dc=com
EOF

modifying entry "uid=amita,dc=example44,dc=com"

4)
ldapsearch -x -h localhost -p 1389 -D "cn=Directory Manager" -w Secret123 -b "dc=example44,dc=com" -s sub "(objectclass=*)" creatorsName createTimestamp modifiersName modifyTimestamp
# amita, example44.com
dn: uid=amita,dc=example44,dc=com
creatorsName: cn=directory manager
createTimestamp: 20110412062039Z
modifiersName: uid=amita,dc=example44,dc=com
modifyTimestamp: 20110412064017Z

5)
ldapmodify -x -h localhost -p 1389 -D "cn=Directory Manager" -w Secret123 << EOF
dn: uid=amita,dc=example44,dc=com
EOF

6)
ldapsearch -x -h localhost -p 1389 -D "cn=Directory Manager" -w Secret123 -b "dc=example44,dc=com" -s sub "(objectclass=*)" creatorsName createTimestamp modifiersName modifyTimestamp
# amita, example44.com
dn: uid=amita,dc=example44,dc=com
creatorsName: cn=directory manager
createTimestamp: 20110412062039Z
modifiersName: cn=directory manager
modifyTimestamp: 20110412064240Z

Tested - OK, Marking as VERIFIED.


Note You need to log in before you can comment on or make changes to this bug.