Problem statement

  -----------------

  might be a bottleneck for applications which are only interested in the data

  It would be possible to load SSSD's NSS plugin ``libnss_sss.so`` with

  ``dlopen`` and call the provided functions directly. But besides being a bit

  control the behavior of the plugin. Hence a new API provider by SSSD to lookup

  Use cases

  ---------

  The first users of the new API would be the FreeIPA ``extdom`` and

  Both plugins are run in threads of the 389ds directory server and to work

  efficiently the current mutex based locking of the connection of SSSD should be

  Additionally ``slapi-nis`` caches results for performance reasons. Being a part

  of 389ds it will be notified if 389ds objects like e.g. id-overrides are

  modified and can drop the cached object. But since SSSD caches results as well

  modification is detected. As a result ``slapi-nis`` should be able to

  invalidate objects in the caches of SSSD to allow a refresh. The ``sss_cache``

  is only of limited use here because it requires root privileges and currently

  Overview of the solution

  ------------------------

  individual thread does not have to wait until the request is completely handled

  by SSSD but can abandon from the request and maybe check later if a result is

  available.

  most of the processing of such request and similar to the lookup requests it

  would be more straight forward to use a flag to indicate that the cached entry

  of the found object should be invalidated.

  invalidate the cached entries of an object would tell the client to bypass the

  memory cache. This is needed because the memory cache will only contain the

  data of object which were directly requested. But the SSSD on-disk cache might

  missing entry in the memory cache does not indicate that the entry is missing

  in the on-disk cache as well. Additionally memory cache and on-disk cache have

  different timeouts which would require the request to go directly to the SSSD

       *                            will contain the actual number of groups the

       *                            user belongs to. With a return value of 0 the

       *                            groups array was large enough to hold all group.

       *                            large enough and ngroups will have the needed

       *                            size.

       * @param[in]  flags          flags to control the behavior and the results of

  SSSD responder side

  ~~~~~~~~~~~~~~~~~~~

  The SSSD NSS responder has to be prepared to accept the flags in the request.

   * SSS_NSS_GETPWNAM_EX

   * SSS_NSS_GETPWUID_EX

   * SSS_NSS_GETGRGID_EX

   * SSS_NSS_INITGR_EX

  will be called so that the cache-request framework will directly request new

  data from the backend.

  ``cache_req_data_set_bypass_dp()`` (which will be implemented with this

  feature) will be called to only search the requested object in the cache. If it

  The flags ``SSS_NSS_EX_FLAG_NO_CACHE`` and ``SSS_NSS_EX_FLAG_INVALIDATE_CACHE``

  cannot be used at the same time.

  How To Test

  -----------

  How To Debug

  ------------

  the debug logs of the SSSD responder are available.

  If the ``SSS_NSS_EX_FLAG_NO_CACHE`` or ``SSS_NSS_EX_FLAG_INVALIDATE_CACHE`` are

  memory cache as expected.

  Authors

  Starting with upstream version 1.12, when the SSSD implemented its

  public DBus interface, the SSSD switched from hardcoding interface

  interfaces in XML files using the `introspection

  format <http://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format>`__,

  which are then used to autogenerate message handlers, property getters