scan-build wrongly assumes that output variable
"version" is not initialized if function sysdb_cache_connect
returns ERR_SYSDB_VERSION_TOO_OLD or ERR_SYSDB_VERSION_TOO_NEW

The reality is that output variable "version" is initialized
especially for these two case. Initialisation to NULL suppresses
these false positive reports.

Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>

There were unused parameter struct ldb_message *cached_group
in sysdb_store_group_attrs().

This parameter was introduced by
40de79d69860ec7f04bf7795bd88b641ec42fd23
SYSDB: Check if group attributes differ before saving a group

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

We ignored failures from sysdb_search_entry

Reviewed-by: Petr Čech <pcech@redhat.com>

The boolean variable newly_created could be used uninitialized
in done section in case of failure. The variable was firstly initialized
to true after succesfull execution of function sysdb_cache_create_empty.

Uninitialized variable usually means true for boolean variable.

Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>

As many users are used to remove the persistent cache without removing
the timestamp cache, let's throw away the timestamp cache in this case.

Resolves:
https://fedorahosted.org/sssd/ticket/3128

Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

As sysdb_cache_connect() has two very specific use cases (connect to the
cache and connect to the timestamp cache) and each of those calls have a
predetermined/fixed sets of values for a few parameters, let's try to
make the code a bit simpler to follow by having explicit functions for
connecting to the cache and connecting to the timestamp cache.

Macros could be used as well, but I have a slightly preference for
having two new functions instead of macros accessing internal parameters
of the macro's parameter.

Related:
https://fedorahosted.org/sssd/ticket/3128

Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

The usage of modifyTimestamp needn't be a reliable way
for detecting of changes in user entry in LDAP.
The authorisation need to rely current data from LDAP
and therefore we will temporary disable optimisation with
modifyTimestamp and we will rather rely on deep comparison
of attributes. In he future, it might be changed and
responders might control the optimization level.

Resolves:
https://fedorahosted.org/sssd/ticket/3110

Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

sysdb is already able to retrieve the current timestamp if the caller
doesn't specify it. However, for the timestamp cache this came too late
and the timestamp cache used zero as the 'now' time.

Resolves:
https://fedorahosted.org/sssd/ticket/3064

Reviewed-by: Pavel Březina <pbrezina@redhat.com>

There was a crash in nss responder when a group contained
a user with special charactes which shoudl be sanitized before
using in filter.

==31651== Conditional jump or move depends on uninitialised value(s)
==31651==    at 0x8BEA7DE: _talloc_steal_loc (talloc.c:1215)
==31651==    by 0x5264889: sysdb_get_user_members_recursively (sysdb_ops.c:4759)
==31651==    by 0x5278F61: sysdb_add_group_member_overrides (sysdb_views.c:1375)
==31651==    by 0x526677C: sysdb_getgrnam_with_views (sysdb_search.c:799)
==31651==    by 0x1172F6: nss_cmd_getgrnam_search (nsssrv_cmd.c:3168)
==31651==    by 0x119C67: nss_cmd_getby_dp_callback (nsssrv_cmd.c:1382)
==31651==    by 0x10FD14: nsssrv_dp_send_acct_req_done (nsssrv_cmd.c:916)
==31651==    by 0x12898B: sss_dp_internal_get_done (responder_dp.c:791)
==31651==    by 0x58FF861: complete_pending_call_and_unlock (dbus-connection.c:2314)
==31651==    by 0x5902B50: dbus_connection_dispatch (dbus-connection.c:4580)
==31651==    by 0x527F261: sbus_dispatch (sssd_dbus_connection.c:96)
==31651==    by 0x89D8B4E: tevent_common_loop_timer_delay (tevent_timed.c:341)

Resolves:
https://fedorahosted.org/sssd/ticket/3121

Reviewed-by: Pavel Březina <pbrezina@redhat.com>