[Date Prev][Date Next] [Chronological] [Thread] [Top]

ldapmodif can delete required attributes (ITS#179)

Full_Name: Heiko W.Rupp
Version: 1.2.1
OS: NetBSD (i386 and Sparc)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (

Create an entry as usual. Then use ldapmodify to delete one of the required
attributes. slapd will report, that this is a objectclass violation (with
shemcheck on),
but deletes the attribute nevertheless which leads to inconsistent data.

The following script will reproduce this; entries are below "dc=pilhuhn,dc=de"

# Test to see if attribute can be removed even if it is a required one

cat<<MOUSE > /tmp/f
dn: cn=test,dc=pilhuhn,dc=de
cn: test.test
sn: test
objectclass: top
objectclass: person

ldapadd -D"cn=master,dc=pilhuhn, dc=de" -w"xxxx" < /tmp/f

cat<<MOUSE > /tmp/g
dn: cn=test,dc=pilhuhn,dc=de
changetype: modify
delete: sn
ldapmodify -v -D"cn=master,dc=pilhuhn, dc=de" -w"xxxxx" < /tmp/g
echo -n "Result code from ldapmodify: "
echo $RES

ldapsearch -L -b "cn=test,dc=pilhuhn,dc=de" "(objectclass=person)" > /tmp/h

DIFF=`diff  /tmp/f /tmp/h`

if [ "x$DIFF" = "x" ]
        echo "Test passed, required attribute not deleted"
        echo "Test failed. required attribute deleted:"
        echo $DIFF

The part of slapd -d 775 logging:
do_bind: bound "cn=master,dc=pilhuhn, dc=de" to "cn=master,dc=pilhuhn, dc=de"
send_ldap_result 0::
conn=1 op=0 RESULT err=0 tag=97 nentries=0
do_modify: dn (cn=test,dc=pilhuhn,dc=de)
        delete: sn
conn=1 op=1 MOD dn="CN=TEST,DC=PILHUHN,DC=DE"
dn2entry_w: dn: "CN=TEST,DC=PILHUHN,DC=DE"
=> dn2id( "CN=TEST,DC=PILHUHN,DC=DE" )
====> cache_find_entry_dn2id: found dn: CN=TEST,DC=PILHUHN,DC=DE
<= dn2id 10 (in cache)
=> id2entry_w( 10 )
====> cache_find_entry_dn2id: found id: 10 rw: 1
entry_rdwr_wtrylock: ID: 10
<= id2entry_w 0x35800 (cache)
removing entire attribute sn
Entry (cn=test,dc=pilhuhn,dc=de), oc "person" requires attr "sn"
entry failed schema check
send_ldap_result 65::
conn=1 op=1 RESULT err=65 tag=103 nentries=0

I don't know if this is the reappearance of ITS#25