Imperfection of new debug levels macros
by Pavel Březina
Hi all,
while working on the sudo I've noticed some semantic issues with debug
level names.
The debug levels are defined as:
#define SSSDBG_FATAL_FAILURE 0x0010 /* level 0 */
#define SSSDBG_CRIT_FAILURE 0x0020 /* level 1 */
#define SSSDBG_OP_FAILURE 0x0040 /* level 2 */
#define SSSDBG_MINOR_FAILURE 0x0080 /* level 3 */
#define SSSDBG_CONF_SETTINGS 0x0100 /* level 4 */
#define SSSDBG_FUNC_DATA 0x0200 /* level 5 */
#define SSSDBG_TRACE_FUNC 0x0400 /* level 6 */
#define SSSDBG_TRACE_LIBS 0x1000 /* level 7 */
#define SSSDBG_TRACE_INTERNAL 0x2000 /* level 8 */
#define SSSDBG_TRACE_ALL 0x4000 /* level 9 */
Unfortunately there are some old DEBUG call that does not correspond
with these names. Look at this snippet from responder initialization:
if (ret != EOK) {
DEBUG(0, ("Failed to set up automatic
reconnection\n"));
return ret;
}
for (iter = sctx->rctx->be_conns; iter; iter = iter->next) {
sbus_reconnect_init(iter->conn, max_retries,
sudo_dp_reconnect_init, iter);
}
DEBUG(1, ("SUDO Initialization complete\n"));
It is ok to replace the 0 with SSSDBG_FATAL_FAILURE (however I would
prefer SSSDBG_CRIT_FAILURE as it does not prevent reponder from starting).
But more important is - I can't use SSSDBG_CRIT_FAILURE, because it is
semantically nonsense. There should be SSSDBG_TRACE_FUNC. But if I use
it, it will differ from other responders and that would be just confusing.
Another problem is that debug levels that are described in the man page
(master) does not correspond the way it is used in the code.
12 years, 5 months
Announcing SSSD 1.6.3
by Stephen Gallagher
The SSSD team is proud to announce the version 1.6.3 bugfix release of
the System Security Services Daemon.
As always, it can be downloaded from https://fedorahosted.org/sssd/
== Highlights ==
* Fixes a major cache performance issue introduced in 1.6.2
* Fixes a potential infinite-loop with certain LDAP layouts
== Detailed Changelog ==
Jakub Hrozek (4):
* Plug memory leaks in LDAP provider
* RFC2307bis initgroups: fix nested groups processing
* Steal result onto mem_ctx in sdap_initgr_nested_get_direct_parents
* Use LDAPDerefSpec properly
Jan Zeleny (1):
* Handle group renaming correctly
Stephen Gallagher (5):
* Bumping version to 1.6.3
* RESPONDER: Fix segfault in sss_packet_send()
* SYSDB: add index for nameAlias
* Fix bad backport of group rename patch
* Update translation files for release
12 years, 5 months
Announcing SSSD 1.5.15
by Stephen Gallagher
The SSSD team is proud to announce the version 1.5.15 bugfix release of
the System Security Services Daemon.
As always, it can be downloaded from https://fedorahosted.org/sssd/
== Highlights ==
* Fixes a major cache performance issue introduced in 1.5.14
* Fixes a potential infinite-loop with certain LDAP layouts
== Detailed Changelog ==
Jakub Hrozek (3):
* Plug memory leaks in LDAP provider
* RFC2307bis initgroups: fix nested groups processing
* Steal result onto mem_ctx in sdap_initgr_nested_get_direct_parents
Stephen Gallagher (4):
* Bumping version to sssd 1.5.15
* RESPONDER: Fix segfault in sss_packet_send()
* SYSDB: Update sysdb version to latest
* Updating translation files for release
12 years, 5 months
[PATCH] SYSDB: add index for nameAlias (master)
by Stephen Gallagher
SSSD 1.6.2 has a major performance issue due to the addition of the
alias support. We added a new attribute to the lookup filter, aliasName.
Unfortunately, we forgot to add an index to it and it's causing a severe
bottleneck in cache lookups.
12 years, 5 months
[PATCH] SYSDB: Update sysdb version to latest (1.6.x)
by Stephen Gallagher
SSSD 1.6.2 has a major performance issue due to the addition of the
alias support. We added a new attribute to the lookup filter, aliasName.
Unfortunately, we forgot to add an index to it and it's causing a severe
bottleneck in cache lookups.
12 years, 5 months
[PATCH] RESPONDER: Fix segfault in sss_packet_send()
by Stephen Gallagher
There are several places (all error-handling) where sss_cmd_done()
is called with no response packet created. As a short-term
solution, we need to check whether the packet is NULL and simply
return EINVAL. client_send() (the consumer) will then forcibly
disconnect the client (which will return PAM_SYSTEM_ERR to the
client).
This is a quick fix for
https://bugzilla.redhat.com/show_bug.cgi?id=748924
We don't have enough information (or steps to reproduce) to trace back
the processing to its origin, so the best thing we can do for the moment
is to simply prevent the crash. The client will receive an error, but
the SSSD will continue to function.
12 years, 5 months