Re: slapd dies on invalid oc modify on Solaris 8 (ITS#1275)

[blair@devclue.com]

The problem does not occur with OPENLDAP_REL_ENG_2.  I (thankfully) get:

modifying entry "uid=blair,ou=people,dc=uchicago,dc=edu"
ldap_modify: Object class violation
        additional info: unrecognized objectClass 'somerandomoc'


I am still able to replicate the problem with an unpatched instance of
2.0.11 slapd.  My patched versions run fine, however, and as I'll be
going to 2.0.12 after it is released, this probably is not much of an
issue.

Thanks,
blair.

On Mon, Aug 06, 2001 at 05:12:49AM +0100, Kurt D. Zeilenga wrote:
> IIRC, this is corrected in OPENLDAP_REL_ENG_2.  Please
> test.
> 
> Kurt
> 
> At 09:04 PM 8/3/2001, blair@devclue.com wrote:
> >Full_Name: blair christensen.
> >Version: 2.0.11
> >OS: Solaris 8
> >URL: ftp://ftp.openldap.org/incoming/
> >Submission from: (NULL) (128.135.0.40)
> >
> >
> >fetish 14:52:53 slapd 633 # uname -a
> >SunOS fetish 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-4
> >
> >If a modify request for an undefined objectClass is received, slapd will die.  I
> >was able to duplicate this bevavior on demand after we noticed the behavior both
> >as the rootdn and any other account that had objectclass write access.  This was
> >using back-ldbm.
> >
> >The syslog entry:
> >
> >Aug  2 17:01:00 fetish slapd[11042]: [ID 492405 local4.debug]
> >  entry_check_schema(uid=xxxxx, ou=People, dc=uchicago, dc=edu): 
> >  objectClass "kerberosAccount" not defined
> >
> >
> >
> >The gdb backtrace:
> >
> >Core was generated by `/opt/pkgs/openldap2-2.0.11/libexec/slapd -f
> >/opt/pkgs/openldap2-2.0.11/etc/open'.
> >Program terminated with signal 9, Killed.
> >
> >(gdb) bt
> >#0  0xfefb3084 in strlen () from /usr/lib/libc.so.1
> >#1  0xff0028d8 in _doprnt () from /usr/lib/libc.so.1
> >#2  0xff004a4c in vsnprintf () from /usr/lib/libc.so.1
> >#3  0xfefd0c6c in vsyslog () from /usr/lib/libc.so.1
> >#4  0xfefd07b8 in syslog () from /usr/lib/libc.so.1
> >#5  0x465f0 in ldbm_modify_internal (be=0xf9588, conn=0xba258, op=0x1164d0,
> >dn=0xba1b0 "iled", modlist=0x0, e=0x3ce2e58, 
> >    text=0xfe603a80) at modify.c:143
> >#6  0x46898 in ldbm_back_modify (be=0xf9588, conn=0x118c28, op=0x1164d0, 
> >    dn=0x3ccfd20 "uid=aaburke, ou=People, dc=uchicago, dc=edu", ndn=0x3cdecb0
> >"UID=XXXXX,OU=PEOPLE,DC=UCHICAGO,DC=EDU", 
> >    modlist=0x3ccb830) at modify.c:232
> >#7  0x30dd4 in do_modify (conn=0x118c28, op=0x1164d0) at modify.c:250
> >#8  0x23dd4 in connection_operation (arg_v=0x116c50) at connection.c:818
> >#9  0x5bd90 in ldap_int_thread_pool_wrapper (pool=0xda370) at tpool.c:377
> >
> >
> >After applying the following patch and recompiling, I have not been able to
> >replicate the problem:
> >
> >*** servers/slapd/schema_check.c        Tue Jan 16 19:52:01 2001
> >--- servers/slapd/schema_check.c.new    Fri Aug  3 14:49:20 2001
> >***************
> >*** 52,57 ****
> >--- 52,58 ----
> >                        Debug( LDAP_DEBUG_ANY,
> >                                "entry_check_schema(%s): objectClass \"%s\" not
> >defined\n",
> >                                e->e_dn, aoc->a_vals[i]->bv_val, 0 );
> >+             *text = "objectClass not defined";
> >                        return LDAP_OBJECT_CLASS_VIOLATION;
> >  
> >                } else {