[Date Prev][Date Next]
Re: (ITS#4179) slapd-meta seg faults if a time attribute is mal formed
On Tue, 2005-11-22 at 11:02 +0100, email@example.com wrote:
> I forgot to precise thant now back-meta FILTERS OUT the bad value (the
> client does not receive the attribute value).
> Is it normal ?
Yes. This has always (as far as I can tell) been back-ldap and back-
meta behavior when processing data they cannot handle; another option
would be to discard the entire entry, but the spirit of the proxy has
always been to let as much as possible pass thru, without violating
standard track rules. I think I considered, some time, the possibility
to allow inconsistent data to pass thru; this may be desirable in some
cases, when the proxy is used as a "dumb" proxy, but it would pose a
number of issues when the proxy is part of a more sophisticated
configuration that needs to interact with other components of slapd
(e.g. the proxy is glued together with a read database, a cache is
placed on it and so; all the other components are a quite strict about
syntax and schema conformance).
In general, either (a) the remote portion of the system (the targets
and/or the client) are broken, or (b) slapd/back-meta is misconfigured
(if it has bugs we're usually happy and willing to fix them, so i
wouldn't count this (c) option).
(a) In this case it's pointless to fix other software bugs in back-meta,
because we cannot keep up with all broken software out there; I'd go for
customization of back-meta (it should be pretty trivial, or you can hire
someone with a solid background on it ;)
(b) You should fix the configuration as appropriate, so that
unrecognized stuff gets recognized. I recently worked on a project
where slapd and back-meta had to interoperact with other software with a
lot of schema issues (loose schema specifications and so) and the
solution was a module that allows to import schema from the remote
servers relaxing some of the constraints of slapd and fixing the most
relevant issues (like the absence of declared matchingRules on
attributes that must be used for filtering; go and see what equality
rule AD declares for the sAMAccountName...).
With respect to your problem I suggest you either go and fix the data in
the remote server, or hack back-meta to sanitize the values before
returning it to the client. There's little room for a sanitizing module
because you cannot (yet?) intercept data between the remote server and
back-meta syntax checks. Another solution, if those values are related
to a custom attributeType, is to change the syntax to directoryString.
Ing. Pierangelo Masarati
Responsabile Open Solution
Via Dossi, 8 - 27100 Pavia - ITALIA