From 12fbe00a8d6a6a4ef84260bb64ad420204f8d1e6 Mon Sep 17 00:00:00 2001 From: js198686 Date: Mon, 26 Jun 2006 02:29:07 -0700 Subject: 4790539 ldapaddent should verify data before trying to add it to LDAP --- usr/src/lib/libsldap/common/ns_writes.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'usr/src/lib/libsldap/common/ns_writes.c') diff --git a/usr/src/lib/libsldap/common/ns_writes.c b/usr/src/lib/libsldap/common/ns_writes.c index 217586e340..8b02e68262 100644 --- a/usr/src/lib/libsldap/common/ns_writes.c +++ b/usr/src/lib/libsldap/common/ns_writes.c @@ -3546,6 +3546,21 @@ int __ns_ldap_addTypedEntry( if (create != 1) { /* Modify the entry */ + /* + * To add a shadow-like entry, the addTypedEntry function + * would call __ns_ldap_repAttr first, and if server says + * LDAP_NO_SUCH_OBJECT, then it tries __ns_ldap_addEntry. + * This is to allow a netmask entry to be added even if the + * base network entry is not in the directory. It would work + * because the difference between the schema for the network + * and netmask data contains only MAY attributes. + * + * But for shadow data, the attributes do not have MUST + * attributes the base entry needs, so if the __ns_ldap_addEntry + * is executed, it would fail. The real reason, however, is that + * the base entry did not exist. So returning + * LDAP_OBJECT_CLASS_VIOLATION would just confused. + */ if ((__s_cvtlist[s].flags & AE) != 0) rc = __ns_ldap_addAttr(service, fulldn, modattrlist, cred, flags, errorp); @@ -3557,6 +3572,10 @@ int __ns_ldap_addTypedEntry( (void) __ns_ldap_freeError(errorp); rc = __ns_ldap_addEntry(service, fulldn, entry, cred, flags, errorp); + if (rc == NS_LDAP_INTERNAL && *errorp && + (*errorp)->status == + LDAP_OBJECT_CLASS_VIOLATION) + (*errorp)->status = LDAP_NO_SUCH_OBJECT; } } } else { -- cgit v1.2.3