Serialize process of initiliazing map cache to avoid locking the
directory server backends.

Initializing map cache may take time. Skip slapi-nis lookups untli
the map cache is ready.

FreeIPA allows to include external (non-LDAP) members into POSIX groups.
To define external members, an attribute ipaExternalMember is set to
the list of references to external members. Currently both FreeIPA and
SSSD support only references done with SIDs (Security Identifiers) from
the forests trusted by FreeIPA.

Resolving external members of FreeIPA groups requires resolving SIDs to
user and group names. However, since this resolution is already
implemented by SSSD for the group in question, slapi-nis can use the
fact that there is non-empty ipaExternalMember attribute's value to
trigger lookup of the FreeIPA group via SSSD and then copy over
memberUid attribute value set.

This logic requires that ipaExternalMember attribute value is present in
the entry to be put into the map cache. Thus, an additional
configuration is needed for the groups container:

schema-compat-entry-attribute: ipaexternalmember=%deref_r("member","ipaexternalmember")

Note that resolving external members of IPA groups requires to use
version of slapi-nis that populates the map cache after LDAP server
startup, as SSSD needs to talk back to the LDAP server in the process of
resolving external group members and that is not possible at the time
when slapi-nis plugin starts up as the LDAP server is not yet listenting
for incoming connections at that point.

When memberUid attribute is generated, it has to be normalized or
otherwise searches for members against groups in compat tree will fail.
slapi-nis already normalizes elements of a search filter that mention
memberUid attribute values but the original memberUid value should be
normalized as well.

Currently slapi-nis design assumes the map cache is populated by
scanning the original trees on plugin start up. This has few
consequences:
   - LDAP server cannot serve LDAP clients until all plugins are
     initialized

   - slapi-nis cannot ask SSSD to resolve external identities at
     this point as SSSD will need to talk to the LDAP server which
     is at this point not listening for connections. SSSD will put
     whole IPA domain into offline and always will respond
     with negative result

To solve these issues, schedule tree scan after LDAP server startup.
The problem here is that it is not possible to reliably detect when
389-ds starts to listen to the incoming connections. However, it is
possible to schedule an event into 389-ds event queue that will run
shortly after start of the event loop. Given that the call back function
which is registered to be called is called within the event loop thread,
one can fire off another thread and wait in the thread function some
time until the LDAP server is ready for connections.

The time interval is something that would depend on a specific
deployment profile but experiments show that having 5 seconds delay
should be enough as event queue is created just before starting the
listeners.

- ID View processing should only happen if ID view is defined
- When finding attribute with slapi_entry_attr_find() use correct return
  code (slapi_entry_attr_exists() returns 1, _find() returns 0)
- cn=<view>,cn=views,cn=compat,$SUFFIX lookup is fixed

Resolves: rhbz#1277576, rhbz#1265465

https://bugzilla.redhat.com/show_bug.cgi?id=1277576
https://bugzilla.redhat.com/show_bug.cgi?id=1265465

When slapi-nis plugin responds on a search query, it holds read lock for
the internal structure called 'map cache'. The map cache lock can also be taken
for write when modification would be required like responding to DELETE, ADD, or
MODIFY operations.

As result of the lock semantics, write lock owner is blocked until all read lock
owners release their locks. This is generally not a problem but when readers sent
out LDAP query results, they call into SLAPI function that might take long time
to send out the data due to external reasons (network latencies, clients being
blocked, etc) and all this time map cache is locked for write operations.

When Kerberos KDC issues a TGT, it needs to modify few Kerberos-related attributes
in the principal's LDAP entry. These updates are generating MOD operations visible
by slapi-nis plugin which triggers re-scan of map cache to potentially replace
the affected entries. To perform potential replacement, slapi-nis has to take a write
lock and be blocked by outstanding readers.

Therefore, it is possible to encounter a situation where an LDAP client uses
SASL GSSAPI authentication and existing Kerberos ticket did expire in a course
of outstanding search request. According to LDAPv3 protocol specification, an
LDAP client must perform re-negotiation before reading any outstanding PDUs. It
would ask Kerberos KDC for a new (or renewed) TGT, that would cause MOD updates
for the primary tree which is tracked for changes by slapi-nis. These changes
would be blocked by a slapi-nis reader as the client cannot finish reading
outstanding PDUs yet.

To solve this problem, we avoid sending LDAP entries while keeping map cache
lock. Instead, we generate a linked list of copies of entries which will be
sent out. To allow sharing of entries between multiple parallel queries, we
hash the entry and reference the cached entry in the linked list with increased
reference count. Once entry is actually sent, its reference count decreased and
on reaching zero it is removed from the hash.

The entry in the hash table might become outdated. This is detected by comparing
both modifyTimestamp and entryUSN values of the entry to be sent and entry in the
hash table. If new version of the entry is different, hash table's entry reference
is replaced with a new copy. The old entry is not removed because it is still
referenced by some outstanding query processing. Thus, the hash table always
references the most recent version of an entry but there might be multiple copies
in possesion of the linked lists from the separate parallel queries.

An entry sharing via hash table can be disabled by setting
        slapi-entry-cache: 0
in the definition, cn=Schema Compatibility,cn=plugins,cn=config

Resolves: rhbz#1273587

https://bugzilla.redhat.com/show_bug.cgi?id=1273587

When describing the NIS and compat filtering options, remind the reader
that indexing the involved attributes helps.

In the case there are no groups in cn=groups map that have certain
memberUid as a member, we look at possibility that this user might
be coming from a trusted AD forest. However, all users from trusted
AD forests do have '@' separator in the name between the user name
and the domain.

In case there is no '@' separator, consider such search as not valid
for lookups in SSSD.

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1243823

CVE-2015-0283 slapi-nis: infinite loop in getgrnam_r() and getgrgid_r()