Re: back-sql auxiliary objectClass attributes -> binary value syntax check?

["Pierangelo Masarati" <ando@sys-net.it>]

> Having back-sql

What version of slapd?

> with iODBC and mysql deployed and set the debugging on,
> I  realized that auxiliary objeclass(s) -those not mapped through
> ldap_entries.oc_map_id  rather through  ldap_entry_objclasses.oc_name-
> is only to represent the  objectClass attribute of the main entry  and a
>  further attribute mapping fetch was not to be seen for those
> objectclasses in case they apply , although the ldap_oc_mappings and
> ldap_attr_mappings were properly configured.

Can you specify what the auxiliary objectClass has to do with it?
ldap_entry_objclasses contains the name of an objectClass that is
added to the structuralObjectClass; mapping of attributes for those
objectClasses must be done thru ldap_at_mapping -- even for those
attributes that do not fit in LDAP's schema for the
structuralObjectClass; schema checks are performed on the complete
entry.

ldap_entry_objclasses is a bit out of sync with the schema-aware
code of back-sql, it is mainly preserved not to break existing
deployments of back-sql but it will be probably removed in a future
major release of the software.

>
> Mapped those ldap_attr_mappings to some alternative main  structural
> objectclass oc_map_id and using joins to acuxilary tables leads to
> retrieve the info but i am afraid the syntax checks will not be
> considered and it leads to not transporting binary information as binary
>  rather as a hexdump string.

Do you mean that binary-valued attributes are not treated as blob's?
In fact, back-sql is assuming that attributes are strings.
A syntax-aware version is under consideration, but there are some
issues (mainly about portability).

>
> The actual case is person objectClass along with using pkiUser as an
> auxiliary objectClass holding the userCertificates and I used the
> inetOrgPerson as the alternative main objectClass.
>
> I already checked the odbc settings with test applications and the odbc
> driver delivers the db blob object in correct binary mode.
>
> Would somebody comment this and let me know how to force the binary
> transfer of those attributess or where is the right place to track that
> down why the transfer is done not in binary mode.

Assuming that you look at HEAD code (fixes or patches to earlier
releases are likely not to be considered), take a look at function
backsql_get_attr_vals() in entry-id.c; there's a comment about what
to do if an attribute has non-string syntax.

Note that back-sql in general has a type/syntax intrinsic problem,
because even string-like values in general should be converted from
whatever charset to utf8 and back.  What is binary for SQL could be
something else for LDAP and vice-versa.  A very special case is
represented by naming attributes and distinguished values (i.e.
those that participate in the DN).

I would ask you to separate the two issues:
a) auxiliary classes (if it is an issue at all)
b) searches returning binary values; this is a known issue that needs
   be addressed.  Patches are welcome.

I'd like to see the problem addressed in a general manner.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it