Handle multiple simultaneous enumeration requests

Previously, if a second enumeration request arrived while one was
already being processed, each process would receive only a subset
of the total number of available users or groups. This is because
we were maintaining the response object as a global value in the
NSS responder. The second request would come in, see that the data
set was already populated, and start reading from wherever the
cursor was currently pointed.

With this patch, we now move the cursor to the client context
instead of the global NSS context.

Additionally, this patch completely rewrites the approach to
enumerations in the tevent_req style. This makes it much easier to
follow in the code.

In order to ensure that a slow or malicious client cannot hold
onto a reference for the setent result object indefinitely, we
set an expiration on the object. We use the enum_cache_timeout
here, since that is an appropriate value.

If the timeout fires during the normal operation of the get*ent()
loop of a client program, we will save the current values of the
read index so that we can resume as soon as the object has been
refreshed by an implicit setent call.

Instead of deleting the enumeration result object immediately
after the last in-progress client has read it, we'll keep the
object around for the lifetime of enum_cache_timeout. This way,
additional clients making enumeration requests can still access
the results in-memory.

0 files changed, 0 insertions, 0 deletions