The attached patch implements introspecting the sbus interfaces as
tracked by #2234.
There is one part of the patch I dislike, but I wanted to get other
opinions, too -- the discard_const in sbus_message_handler(). I was
going back and forth on whether sbus_introspect() should be an sbus
handler like the other handlers or whether I should special case it (and
then pass the interface directly and not through a void pointer).
Special casing the introspection might be a bit cleaner, but would cause
some duplication in sbus_message_handler().
The other question I have is whether there should be a way to mark an
interface as not introspectable? I can't think of a reason, so by
default all interfaces can be introspected.
The introspection also doesn't generate DocString annotations yet, I
will send a patch for that separately.
I recently started working on ticket #1991.
"The return codes of various sysdb operations differ. Some search
operations would return ENOENT if they don't find a matching object some
would return EOK but an empty result list."
I think that the core of the problem is the expectation that ldb_search
returns LDB_ERR_NO_SUCH_OBJECT in case no results were found. But it
instead returns LDB_SUCCESS and sets result->count to 0.
I think it would be best for sysdb functions in case that no results
were found to return both ENOENT value and 'properly' empty list.
Thanks for opinions.
our current HOWTO on connecting SSSD to an AD DC is outdated,
mostly because the page still only introduces the LDAP provider. Recently, me,
Sumit and Jeremy Agee wrote a new page that specifically advises to use
the AD provider and also use realmd for setup:
We started a new page and kept the old one around mostly because pre-1.9
versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can
link the wiki page from the front page or the documentation section. In
addition to the lists, I also CC-ed the individual contributors to the
original page directly..I hope that's fine.
Thank you for your comments.
These two patches add missing CFLAGS/LIBS to Makefile.am:
[PATCH 1/2] BUILD: Link libsss_ad.so to sasl libs
[PATCH 2/2] BUILD: Use OPENLDAP_CFLAGS instead of LDAP_CFLAGS
This underlinking was noticed in make check (dlopen-test).
It failed for me since my openldap build had no sasl support,
which would otherwise have pulled in libsasl2.so.
Of course, that support should be in place, but the linking should still be
BTW: It would propably be nice to have a configure check whether
openldap has sasl support, but it seems that would need a check if
ldap_sasl_interactive_bind returns LDAP_NOT_SUPPORTED.
I'm sending some patches that I'll use for OpenLMI provider. It supports
few modifications of sssd.conf through augeas.
For the moment, I think we should not bound to any particular API so
even though I made it a separate object, I don't have any intentions to
make it publicly usable library.
This code will be used from D-Bus responder. I may extend the API if needed.
Unit tests are attached.
The attached patch implements the LDAP component of the GPO-based access control project. For more details on the project, see https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryGPOIntegration. The project is not yet complete, since the SMB component still needs to be implemented. However, this seems like a useful milestone to allow others to review the code. This is my first patch submission to the list, so any feedback is appreciated.
In order to exercise the code in your AD environment, you will need to link a GPO to the site, domain, or OUs, associated with the policy target (i.e. domain member computer). Since we are not yet retrieving any policy files (over SMB), there is no access control taking place yet, meaning that any policy settings can be used in the GPOs. The only way to determine what is going on is by examining the logs.
In summary, the code currently does the following:
1. Determines the DN of the policy target (e.g. "cn=f20-laptop,OU=West,OU=Sales,DC=foo,DC=com")
2. Calculates the list of SOM DNs (Site, Domain and OUs) associated with the policy target DN
3. Retrieves various LDAP attributes from each SOM DN in order to populate a list of GPLinks (i.e. GPO DN plus GPO Options)
4. Creates a prioritized list of GPO DNs based on SOM Priority, Link Order, and GPO Options
5. Retrieves various LDAP attributes from each GPO DN in order to populate a list of candidate GPOs
6. Converts the candidate list to a filtered list, by removing any GPO that has a DACL which denies the policy target permission to apply the GPO
7. It is this filtered list that will be sent to the Short-Lived GPO Child process, which will make the necessary blocking SMB calls