Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD

[masarati@aero.polimi.it]

>
> On Jan 26, 2011, at 9:15 AM, masarati@aero.polimi.it wrote:
>
>> The complexity of handling this nonsense in libldap seems not worth the
>> effort;
>
> Ando, you are too kind to refer this extension as 'nonsense'.  It's worse
> than nonsense, it's crap.
>
> The spec you pointed at says: "LDAP servers often place limits on the
> maximum number of attribute values that can be retrieved in a single
> query."

I'd reword that as "One specific LDAP server places limits on the maximum
number of attribute values that can be retrieved in a single query."

> The spec fails to say why would a server want to do that.  I
> cannot think of any good reason to do precisely that.  While I can
> understand a desire to place limits on what clients can retrieve, I don't
> see why one would distinguish between a single query and a set of queries.
>  I can also see it desirable to allow a client to page through results
> (but that's a different matter, this is about forcing paging onto
> clients).
>
> It is incredibly stupid to require clients to use multiple operations to
> obtain information for which the protocol allowed to be fetched in a
> single operation, and this is why I refer to this as "crap".

:)

> A major problem with paging, whether server-forced or at client-option, is
> result set coherency due to changes to the DIT between when various page
> operations are obtain.  This can lead to problems such a member of a group
> not appearing in the results.  While one might argue client might be able
> to reasonable deal with coherency issues, most client developers won't.
> This will lead to a range of security issues creeping into directory
> applications.
>
> So while I don't generally oppose introduction of paging extensions at the
> client option, I think the specifications should warn that the clients
> using them need to be designed to handle data coherency issues. However,
> most designers of such extensions seem to have put no thought into this
> issue at all.

Well, I don't see paged results as a way to introduce more inconsistency
than a regular search operation, since nowhere in the specs I see that the
collection of the entries returned by a search are consistent with the
entries matching the search request at a specific time (e.g. when the
operation was initiated or so).  As a consequence, clients need be aware
of the fact that search results can be inherently inconsistent, paging or
not.

> I do generally oppose introduction of non-truly optional extensions in
> LDAP (and in other application protocols).   One would think that a
> requirement that extensions to a protocol be truely optional would go
> without saying, but in IETF we actually found it necessary to explicitly
> state this in the BCP governing LDAP extensions.
>
> That BCP will effectively stop non-truly optional extension proposal as
> this from gaining Standard Track status in the IETF.
>
>> I think we might consider working this around in proxy backends
>> (much like we did for unsolicited paged results response in back-meta,
>> ITS#6664, which could be added to back-ldap as well).
>
> I would think it easier to reconfigure AD not to have the limits which
> cause this sort of paging.

Of course.  The whole discussion about this issue (and others) and often
the thrust that pushes the development of many features in the proxy
backends (and other features, like slapo-rwm, slapo-translucent and more)
is the practical impossibility to affect the configuration of one or more
remote servers.

p.