ldb 1.3.2 fails some tests

[Garming Sam]

The duplicate syntaxes appears to occur here which triggers in the ldb_init.

The flags are set as 0, meaning they are not marked
LDB_ATTR_FLAG_FROM_DB and so are never unloaded. Because qsort seems to
trigger a stable-sort, it manages to pick the one without the
UNIQUE_INDEX. One other thing I notice is the the test sets
UNIQUE_INDEX, which will by default fallback to OCTET_STRING if
CASE_INSENSITIVE has not been set, which is why there is also an oid
difference.

/*
  setup the attribute handles for well known attributes
*/
int ldb_setup_wellknown_attributes(struct ldb_context *ldb)
{
        const struct {
                const char *attr;
                const char *syntax;
        } wellknown[] = {
                { "dn", LDB_SYNTAX_DN },
                { "distinguishedName", LDB_SYNTAX_DN },
                { "cn", LDB_SYNTAX_DIRECTORY_STRING },
                { "dc", LDB_SYNTAX_DIRECTORY_STRING },
                { "ou", LDB_SYNTAX_DIRECTORY_STRING },
                { "objectClass", LDB_SYNTAX_OBJECTCLASS }
        };
        unsigned int i;
        int ret;

        for (i=0;i<ARRAY_SIZE(wellknown);i++) {
                ret = ldb_schema_attribute_add(ldb, wellknown[i].attr, 0,
                                               wellknown[i].syntax);
                if (ret != LDB_SUCCESS) {
                        return ret;
                }
        }

        return LDB_SUCCESS;
}

Cheers,

Garming


On 04/03/18 20:15, Andrew Bartlett via samba-technical wrote:
> On Sun, 2018-03-04 at 06:32 +0100, Timur I. Bakeyev wrote:
>> So, array of attributes schemas gets two definitions for "cn" attribute with different handlers. I'm not sure, if this is a correct behavior at all,
>> but current code allows such an addition through the ltdb_attributes_load()->ldb_schema_attribute_fill_with_syntax() sequence, while
>> doing proper definition replacement in the ldb_schema_attribute_add_with_syntax().
> The from-DB load tries to avoid the attribute load becoming O(n^2) by
> not calling the 'check if it already exists' case, so that much is
> deliberate.
>
> How it gets declared twice is the next thing to work out.
>
> Thanks!
>
> Andrew Bartlett
>