Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)

[masarati@aero.polimi.it]

> masarati@aero.polimi.it writes:
>> Well, the fact is that memberURL is stored in the data.  As soon as we
>> accept that value, we need to deal with it.  The current behavior of
>> slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be
>> parsed).  We should rather reject values like this when written in the
>> database, but this would probably break other applications.  So I
>> believe the fix is better than silently ignoring these values.
>
> I disagree.  Data validation in LDAP is generally the user's job, LDAP
> syntaxes are very rough in that regard.
>
> If this is a fix to make dynlist compatible with the rest of OpenLDAP's
> handling of URLs in data (e.g. the ref attribute), then this is a good
> fix and I'm way to late to complain.  But in my view, if this fix is
> introducing an incompatibility with the LDAP spec, then it's not.

Data validation is the user's responsibility, but here we're using user
data (an LDAP URI) to perform internal operations, so if we want to be
strict, we should do it when the user writes the data, not when we are
going to use it.  This fix allows the overlay to use poorly formatted data
since we cannot prevent the user from using it.

A better fix would be to intercept write operations that modify entries in
a manner that would trigger slapo-dynlist(5), and be picky about how URLs
are written.  This would not fix existing databases, nor handle cases
where slapo-dynlist(5) is configured using slapd-config(5).

Or, we could simply become picky about how LDAP URIs are written in general.

p.