RHEL 5 has a very old version of doxygen that does not search the
correct locations for documentation.
In the future, we may try to work around this, but for the purposes of
getting the builds back up and running, we should just disable building
docs on RHEL 5.
We were incorrectly using DBUS_ERROR_TIMEOUT here. The correct
behaviour is to check for DBUS_ERROR_NO_REPLY. This way we will
properly handle the three-tries in the tasks_check_handler().
D-BUS is rather confusing with these error codes.
DBUS_ERROR_NO_REPLY: No reply to a message expecting one, usually means
a timeout occurred.
DBUS_ERROR_TIMEOUT: Certain timeout errors, possibly ETIMEDOUT on a
And just for added confusion, there's also:
DBUS_ERROR_TIMED_OUT: Certain timeout errors, e.g. while starting a
DBUS_ERROR_NO_REPLY is the only correct one for our usage. This explains
the intermittent bug we were seeing where the monitor lost communication
with its services (usually the data providers). Because of this loss of
communication, the monitor was unable to notify the providers of changes
to the routing table or resolv.conf, leading to being stuck offline
until SSSD was restarted.
This is probably the root cause of
I've been cleaning up Arun's code for a couple of days and I'd like to
discuss it a little bit.
Please checkout the latest version at:
branch: sudo-arun (Arun's original)
First of all, I would like to point out I don't actually believe Arun
has ever tried it's functionality because the code contains some errors
since commit from 08/10 (11 commits ago).
You can see I've rewritten the coding style of
sbus_dbus_messages_helpers.c and sudo plugin. Removed some warnings and
the errors mentioned above. I've emailed Arun two days ago, asking him
to rewrite coding style of sudo responder, but he hasn't answered yet.
SUDO plugin API documentation:
1. I've added some questions of mine marked with TODO to sss_sudoplugin.c.
2. He's using sometimes fprintf/printf. I believe we should use only
printf/conversation function given by sudo in policy_open().
3. While creating hash tables of settings and envirement, he's
converting all booleans to string (which currently causes 'discard
const' warnings). I'm not very familiar how these hash_tables are
transferred via dbus but I believe it can be transferred as integer?
4. It looks to me like he's sending to responder settings and user_env
which are given by sudo in polici_open(). I think we should pass
settings and user_info.
5. To communicate with responder, he uses (struct
sbus_interface)->methods instead of struct sss_cmd_table.
6. There is warning about not initialized init_session field of
policy_plugin struct. I have sudo Sudo version 1.8.1p2...the plugin api
version is still 1/1. I'm not sure if they updated the api or not.
7. There's still an error which blocks compilation: libtool:
link: cannot find the library `libsss_util.la' or unhandled argument
I don't know what to do with it, makefile looks ok to me.
I'm starting to implement the "multiple search bases" feature requested
I want a bit of input on my design (Original text at
I don't expect there to be any disagreements about the individual lookup
case, but I'm not sure if there will be contention around the
enumeration decisions. Recommendations are welcome.
== Purpose ==
Some deployments use search bases to limit or extend the set of users
and groups visible to a system.
One common example is for applications granting access only to users in
a hard-coded group name. In this case, the group search base would
generally be set differently for each machine running this application.
Other machines running the same application providing access to other
users would receive a different "view" of LDAP through the use of search
== Expected Behavior ==
=== Individual Lookups ===
For targeted lookups (e.g. getpwuid(), getgrnam()) we should try each of
the search bases in order until one of them returns the entry we are
looking for, or we have exhausted all of the search bases. Each search
will be performed with the search scope provided.
=== Enumeration ===
For enumeration, we will need to iterate through ALL search bases to
retrieve users, groups, etc. For each search base, we need to examine
each entry retrieved and compare it against the entries received from
earlier search bases. If there are conflicts, we will discard the
conflicting value from the later search base. (Therefore the entry in
the earlier search bases will always win.
== Implementation ==
We will extend the ldap_*_search_base options to support behavior
similar to that of nss_base_passwd and nss_base_group from nss-ldapd.
The standard search base (ldap_search_base will be left alone as a
single value with scope "subtree".
The new ldap_*_search_base options will include a new delimiter, '?'. If
this is present, we will divide the string up into triples as follows:
=== Parsing ===
We will split the input string on the '?' delimiter. If the resulting
array is exactly one, or is a multiple of three, we will continue.
Otherwise it will fail validation.
The scope must be one of 'subtree', 'onelevel' or
The filter will be optional and may be a zero-length string. The filter
must be pre-sanitized and must pass filter validation with
[PATCH 1/2] Improve documentation of libipa_hbac
New, complete doxygen documentation for libipa_hbac. Produces HTML
[PATCH 2/2] Add libipa_hbac documentation to the -devel package
This patch adds the new HTML documentation to the spec file. It
explicitly suppresses the doc output of the main package, since this is
useful only to developers of SSSD itself and is incomplete to boot.
John Hodrien found out that when paging is used while dereferencing an
entry, sssd_be may segfault on the second page.
This was because paging returned the control to sdap_generic_search
multiple times but sssd was freeing dereference control after the first
search invocation. The subsequend sdap searched accessed memory that was
John confirmed off-list that this patch fixed his issue.
I was also considering copying the controls into the search request, but
it seemed like a pointless allocation.